Using document.activeElement at the time of the unload
event as a proxy for whether the user is switching to VE.
Switching to VE is weighed more heavily than whether or not
the user made changes: switching to VE causes abort.type to be
'switchwithout' regardless of whether changes were made; only
if the user isn't switching to VE do we look at whether changes
were made and use 'abort' or 'nochange' as appropriate.
When wgAction === 'submit' (i.e. we're on a preview / show changes
view), it is assumed that the user has made changes.
Bug: T95938
Change-Id: Ic91b87c4fc5b601e1fd98b237100d808e97400bd
If the server-generated editingStatsId was sampled out, we never sent
it to the client. This made this code confusing and difficult to test,
but it also caused a bug: the client-generated editingStatsId
(for when the user presses back) has no place to go in that case,
and gets dropped on the floor.
Bug: T95919
Change-Id: I05adb7116f1a8b91a9e54dfa70c745f12d7fbf3c
Needed because session IDs can be generated on the client
from the unload handler (when the back button is used).
Bug: T95919
Change-Id: Iac921bc36806205fc11ac76154ed8b3890f10d31
So that the ID isn't reused when the user uses the back button
to navigate back to an edit page.
It would be more natural to use pageshow for this, but that
event also fires on initial load. There is a .persisted property
that indicates whether the page was recycled, but that
property doesn't work in Chrome:
https://code.google.com/p/chromium/issues/detail?id=344507
Doing this from pagehide doesn't work either, because that
runs before unload (at least in Chrome) and causes the
abort event to be emitted with the new ID. So instead,
regenerate the ID in the unload handler after the
abort event has been sent.
Bug: T95919
Change-Id: I20a602a7896e75ffa116dcd2c137306ca84164b6
ext.wikiEditor.js calls mw.user.getId() which sometimes causes
a JS error if WikiEditor loads faster than mw.user.
Change-Id: Ib2ca433a8785bebda241cc9095a80036b09b8e44
Some very weird issues going on involving multiple wikiEditor instances being
set up on the same textarea element. It's probably a race condition of some
sort and I'm hoping that restoring the modules like this will fix it.
Bug: T93384
Change-Id: I44c9c013993220ab709893d239614552d7b25d46
Follows-up 74da530f2, which introduced a separate HTTP request
on all pages just for the 665 bytes (compressed) of ext.wikiEditor.init.
Have it join the main load queue instead.
Change-Id: I9e0ce994e632c64f3c781f45ea44582c0a943c65
* No features have a 'configurations' setting, nor can I see any
client-side code looking for any. Was triggering phpcs because of
the 'global $$configuration;' line, which didn't start with "$wg".
* Remove unused selenium tests that were also triggering phpcs.
* Add composer.lock and vendor/ to .gitignore
Change-Id: If06a08b6a7c232ac69f9dff569ffa3e1c93ff0c5
Seems to be causing errors on view (!) on plwiki, and I would not expect this
to work on non-wikitext pages.
Bug: T93242
Change-Id: I0336a85a2ab4bef1d20086382012047688ffa909
