screenshot
Steps to reproduce:
1.Click on the Edit beta button
2.Switch to Edit Source
3.Switch back to VE
4.Click on Cancel
5.Reload the page
Observed Result:
Even after cancelling the edit, in the URL "&veaction=edit" still remains appended , therefore after reloading the page, VE opens up.
Version: unspecified
Severity: minor
Attached:
I can't reproduce this on mediawiki.org or en.wikipedia.org, but I can locally and on en.wikipedia.beta.wmflabs.org
It should be reliably reproducible on all of the above.
It happens when you access veaction=edit directly in the url on a fresh load.
Chrome has the nasty habit of firing a popstate event (sometimes?) on a regular load that wasn't via the history.
This can be worked around by storing a piece of data with the state and using that to tell events apart (to distinguish between a state pop to one we pushed/replaced into the history, from a pop state to one some other application pushed in or one the browser is faultily firing, like Chrome does).
jquery-pjax (the plugin GitHub uses to ajax navigate everywhere, powered by popState), does the same thing. Generate an ID or tag, store that with the push/replace state, and on the popstate, use that to identify ours and ignore others.
This will fix lots of other potential bugs as well.
Assigning back to me as it's on my mind now, might as well fix it.
Change 118357 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Tag our state changes and reject foreign states
Rephrasing bug.
There is explicit logic in place to not update the url sometimes. This is for when we're reacting to a popstate event (e.g. you open VisualEditor from the read page, this activates the editor without a refresh, if you then click back, the browser has already updated the url and it is now telling us to react to that, we don't want to update the url again in that case).
Whenever the editor is initialised in Chrome by direct query parameter (e.g. by clicking "Edit" on a page where we don't load visualeditor, e.g. MediaWiki's Edit source page), the weird initial popstate fired by Chrome was misinterpreted as a dynamic state change.
Then, when leaving the editor, we still think we're reacting to a popstate event so we don't touch the url.
Change 118357 merged by jenkins-bot:
mw.ViewPageTarget: Tag our state changes and reject foreign states