Instead of getting wikitext from the HTML, which is probably
slower and leads to issues with the whitespace stripping hack,
override getDocToSave and get text from the linmod directly.
Bug: T144621
Change-Id: I6b6cf16ee8f3720398ba8f5c85e7715c2e68329f
So we ensure we send the actual revision ID, not potentially undefined, to the
method. If we send undefined, it'll give us an etag for revision number 0...
And that will cause issues when we later attempt (in a future editor switch) to
pass an etag for revision 0 along with the correct revision.
Bug: T143920
Change-Id: I0c27956abdd26ae4f5f1b91010a5eab8ee0354ab
Perhaps in the future we could enhance this so that clicking a different edit
link queues that up for after the current activation finishes / aborts the
current activation cleanly.
Also, error-checking on setting an invalid progress state when loading.
Bug: T143160
Change-Id: I6c78cb19953df6fb564c06bac807e6897b63df19
To align with the linked patch in MediaWiki core. Taking advantage of
the opportunity to use core's messages for these, and remove some dead
wood old messages that were never used like "restore" items in mobile.
Bug: T139033
Depends-On: Ie81b5edd275963a965cd44d0fd325cae9ee2f1a6
Change-Id: Ie00e94cc77cb750a7e8d1104366bb3dad65af8a4
Pretty much fix everything on the insert menu... RB doesn't like it when you
try to specify both title and revision ID, but don't provide an ETag.
Change-Id: Ib25d023309d984ed8848f67b349b23231f27a957
If you viewed a page with an ?oldid= query parameter set to the ID
of the current revision, some parts of VE would believe we were
in oldid mode (because there's an oldid present), but others
wouldn't (because the revid we're editing equals the newest revid).
This caused bugs when opening the editor a second time after saving
(which is normally impossible to do after an oldid-mode edit, because
we navigate to a new page after an oldid save, but we don't do that
in this case).
Ensure that:
* The internal state of DesktopArticleTarget is updated correctly
after saving in this case
* The ?oldid= parameter is removed from the URL after saving
* DesktopArticleTarget.init doesn't preload the article HTML
on a second/subsequent editor load: this causes issues because
it caches the oldid, and generally speaking the Target's internal
state is not considered
Bug: T141330
Change-Id: I74034328797c59f7249f1f6f4f53a92ee1c26334
When our remember-last preference changes work, alongside changing the
label of the edit tab, also change the label of the edit section links.
I seriously have no idea WTF I was thinking back in December when I
put some of this code into #activatePageTarget.
Bug: T137424
Change-Id: I581c0acf0a3ad11ad3bcf4e2e46242907ca9166f
If you deactivate without saving (e.g. using the back button), the page
contents aren't replaced and so adding the page click handlers is pointless
and harmful because they will run twice.
This was my fault in Iad1713e1
Bug: T135387
Change-Id: I3c83009bfc0f42125cdcde7f7a51de9bc2f72abf
So if the user supplies a summary in VE, WTE with the "Prompt me when entering
a blank edit summary" preference won't moan.
Bug: T135979
Change-Id: I0e2d2b6f8fb03bb56d600f1118daf82fb3715b66
In case we were switching to source.
Normally MWWikitextSwitchConfirmDialog#getActionProcess would do this for us,
but this closeWindow call doesn't trigger that, we can't get it by overriding
MWWikitextSwitchConfirmDialog#close either.
Bug: T134333
Change-Id: I66a12ff6d13601250b9d470e1be54fe38a1ef06c
* Ensure ve-loading isn't removed early
* Quickly detach then reattach the loading bar during
activation so it doesn't get moved and marked as original content
Change-Id: I263c9627348953a11966f8bcc435d0d89b0b6084
T52720 (link corruption in FF13/14) appears to be fixed.
T52780 (editor not loading in FF11/12) appears to be fixed.
FF11 has a new issue where templates are normalised even
when not touched (T136607)
Change-Id: I34358e3d90b8186e6b89c04c038ab79c908fc81b
