When you clicked the Back button in the browser, the URL
in the address bar would change (removing veaction=edit),
but we would not go back to read mode. This was broken
by 5c0c11753 almost a month ago but apparently no one noticed.
This is because 5c0c11753 moved the pushState() calls to
be earlier (in init init), making the replaceState() call
in the ViewPageTarget constructor (which is there
specifically for this bug) run too late in those cases.
The simplest way to fix this is to duplicate these replaceState()
calls before the pushState() calls in init init.
I feel a bit bad about copying code, but not very bad
because the code I'm copying already has a FIXME comment
about how there should be a better way :P
Change-Id: I6627a5d1d9377ae815bc58bceeb059ce9f4f19ab
Just like DOM interfaces such as document and location. And JS
constructors like Object.prototype, and libs like jQuery.
No need for the window host object.
Change-Id: Ie39aaea2ca17bdec5fb3afe32a4e6c9f751bd0c6
The location object is a global, just like document.
Using it via 'window' needlessly adds complexity and, for example,
makes it harder to catch typos in static analysis.
Standardise on location.href in place of the many different
variants for accessing and assinging the full url:
location =
location.href =
location.assign() =
And each with 'window', 'document' and without host object.
Change-Id: If88515bd88fc5b93ebacd4ec41fce02fec540f18
mw.msg can return things with <br />, which we want to be interpreted as HTML
rather than just escaped as text.
Bug: 73571
Change-Id: I7861432d9361e01f9def0578c342e60715c3d764
ApiEditPage can give us 'nochange' instead of the
'oldrevid'/'newrevid'/'newtimestamp' keys if we gave it a null edit.
Bug: 73463
Change-Id: Ic22597dfed11de3823471673404090a9bce12928
The container is zero-height and zero-width, so jQuery doesn't
consider it :visible, and yet it still takes up visual space.
Bug: 72693
Change-Id: I3bed5394a2a64a9f7f0a331f850aa412b5b11b7d
Moved the spinner code from ViewPageTarget to ViewPageTarget.init to make it appear immediately on clicking edit.
Bonus: also fixes the URL to add the parameter vesection when clicking a section edit link.
Bug: 65453
Change-Id: Ica33de675203cc0f0594b8362731c4e98a644313
Just hide them when opening the editor and show again afterwards. Will
need Parsoid for proper support.
Corresponding patch in core: I2389ff9a5332a2b1d033eb75f0946e5241cfaaf4.
Bug: 23796
Change-Id: I3ce5e7869be50dcd189ca24e2b3d7ebc62de4fc4
New changes:
8d5ec7a [BREAKING CHANGE] Rename ve.Document.getNodeFromOffset to getBranchNodeFromOffset
Local changes:
* Update calls for rename of getNodeFromOffset to getBranchNodeFromOffset
Change-Id: Ibc69f5a5deeed5698368bb19b30f14497c579e90
Instead of doing a blocking overlay, we're simply keeping the dialog open,
which is necessary for the pending status of the action buttons anyway.
Requires Ib2c8f336 in OOUI
Bug: 65012
Change-Id: I65b5de4a1666a81b157a71f6fec490007689eb44
That function needs to return the result immediately, not wait for module loading (via mw.notify).
This was breaking us being able to keep track of what wikitextWarning object was in use (but only
the first time we used the module), and therefore fail to close the warning when the wikitext
disappeared.
Bug: 70168
Change-Id: I0f1427423a5fe82ec8e70e2f0462a3044ca7ace8
IE doesn't accept null as a "do nothing" value, only undefined.
If you return null, it'll show a popup with the text "null".
Change-Id: I984a7ded483c4c178cbca2a9af9abd895e6ded56
If there is more than one span in #firstHeading, we only want to
update the first one.
This will still break if something inserts elements *before* the title
span, but fixing that would take more thought (we probably should
rebuild the entire heading element and fire 'wikipage.content' on it).
Bug: 69857
Change-Id: Id78b9b8275a57c9b3f3f1dbd0aaca356f94d0f03
The class provided a minimal coupling to the firsteditve guided tour,
which used it to attach a guider to the "Save page" button.
The class was removed in I30dc7020121f0dd6907b61ef674a7cb14eb00652.
Bug: 69784
Change-Id: I81fdc4f2fa41c86a6481cf478c154b5d6c99d41d
The window refactor removed the 'teardown' event from windows,
but ViewPageTarget was still listening to this event on the save dialog.
Instead, use the opening promise to be notified when the save dialog
closes and call onSaveDialogClose() at that time.
Change-Id: I31a9a359eb14a56b214a1240db08632bda6bc8b9
Because this breaks other subtitles such as subpage breadcrumbs
Instead, deal with the #redirectsub (added in I780c965) directly.
Bug: 68432
Change-Id: I646868916a4480404f6d466fd89f84798d0e9df5
It's unnecessary, big and ugly, way too close to an actually useful button, and
adds oodles of complexity to the mire that is VPT without significant user benefit
whilst taking up an unjustifiably huge amount of the already-over-burdened space.
This means that the minimum browser width for English on default Vector to show
the toolbar correctly is now 945px, down from 1029px.
Bonuses: fix MWCancelConfirmDialog's cancel button to be destructive (it is) and
remove a now-recently-fixed comment asking for the save button to be styled using
a generic class (provided by the constructive flag).
Change-Id: I30dc7020121f0dd6907b61ef674a7cb14eb00652
Closing a dialog with specific data means closing it again with
potentially different data, while the dialog is already closing, means
someone wins and someone looses. Silently failing in this case is bad,
because if the first close call was a cancel, producing no side effects,
but the second close call would have produced some side effect, the side
effect would never occur.
The problem here really was that the save dialog needs to be closed
before we can destroy the surface so we can uphold the assumption that
hold and teardown processes are operating on an attached DOM.
The solution is to automatically close the save dialog on teardown,
rather than on save. Since save triggers teardown, this has and identical
user experience.
Bug: 68048
Change-Id: I669448739f168737d4eddd6496189a819ce894b1
