These are not specific to desktop.
Also make the static builders static, and move VE target specific
code to caller, such as the click handler.
Change-Id: Ib7e769e3d6d339b9e66e1bc924480b0b0d5db17d
It's possible for some load failure states to cause this teardown at a point
without a surface. I observed it in MobileFrontend, when restbase can't be
contacted.
Change-Id: I13489640759c73dad5730d0bbadbfb2a38cb8e53
Always store immediately if fromEditedState is true. Also
now that we only store if there is state to recover, remove
the check for transactions before deciding to show the notification.
Change-Id: I5357a9098b91e303f5c71881ea03a080d2969fff
1. It wastes valuable time during setup.
2. If a user reloads the page without making changes we
should give them the latest html from the server to
minimise the chance of an edit conflict.
Change-Id: I9a1f8cfd65ef2552fe2c3d6d2bbf975851b52003
Ensure we start with the same HTML (i.e. if an edit has
been made since the crash-recovery):
* Whenever an article target is activated, stash the initial
document html, other parsoid response data, and the request
parameters (pageName, mode, section) in session storage.
* Whenever an article is fetched through the target loader,
recover from session storage if the request parameters match.
Store transactions:
* On document transaction (debounced) append the latest
changes to session storage.
* If a document state is recovered from session storage,
attempt to re-apply the stored transactions.
Clear transactions:
* Whenever the target is torn down (i.e. save, deliberately
closing the editor to go back to read mode)
Other:
* If writing to session storage fails once, disable future
attempts for that session (assume storage quota exceeded)
* Disable tempWikitextEditor when recovering. We don't have
the transaction code loaded yet to perform the recovery.
Bug: T57370
Depends-On: I3832243fc347a99641fcb7e39a887a153c9a3b22
Depends-On: I448fb566fe9f7f5b5a76e88b70ca000e3d35b415
Change-Id: Id9d877f903cf4796a52f90991c030417a9f8786f
mw.storage catches errors, so we won't crash horribly when the user has
localStorage disabled / full.
Bug: T181822
Change-Id: I212994eb535b9a8fb5f6c09deaa10b16c3d7f10e
Accesskeys in this situation are unreliable cross-browser. Firefox won't
trigger the accesskey inside the dialog. We can manually simulate it, via the
existing trigger.
Bug: T121183
Change-Id: Ib919d8b9fcd9324a517037bcc6ef93a26d1488b9
We need this hack when visually editing articles, but not in e.g. the
Flow integration. Move it down so that mw.Target has a clean
parseDocument method that can be used by Flow without undesirable
newlines being introduced.
Change-Id: I52bba88b3d33c3d6d16c4cf832f23f970a243abf
Idea being: preload use case is often "load content, maybe with parameters,
immediately save it", so we can treat it as being already-modified for saving
purposes.
Bug: T179063
Change-Id: I35ff04bc9cb5172edf8174832624145973aa1fdb
* Rename 'deactivate' to 'tryDeactivate' as it may prompts
the user to deactivate.
* Merge 'cancel' and 'teardownSurface' in to 'teardown',
extending the parent method.
* Rename elementsThatHadOurAccessKey to $saveAccessKeyElements
and move teardown to parent class where it is setup.
* Move toolbarSaveButton teardown to parent class where it is setup.
* Cleanup changeDocumentTitle
Depends-On: I9d97614695272dca6936ef6f3461178fcf0368a8
Change-Id: Ie998a04c21f6615b4415edf471310db5edca3b5a
The default value of target#pageName is wgRelevantPageName
but other targets my override this, or change it dynamically
(e.g. ContentTranslation).
Also remove duplicate setter of pageName in mw.ArticleTarget,
already set in mw.Target.
Change-Id: Iebd1def1d4142978a673afec584a0b663644d176
Other page state is read directly, rather than passed in.
If we come up with a use case for passing this in at a later
date we can reconsider the best way to do this.
Change-Id: Iee7e608c969776b89dbb38b3b56a5177e48344af
Instead, use getCheckboxesDefinition(), and build our save form
checkboxes from that rather than extracting them from the HTML.
The ability to have non-checkbox fields there is removed, as that was
never intentional and is now impossible.
To avoid transient problems during deployment (old JS code cached in
the user's browser receiving the new format of API responses), the old
property is kept in the API response. We should remove it next week.
Bug: T174613
Bug: T174686
Change-Id: I5bfca5e116fe790302c3b6ac1357e80237fb1ed2
ve.init.mw.Target.static.parseDocument requires that its parameter be
a complete HTML document with a single root tag, otherwise some of its
workarounds break horribly in IE 11 (and possibly Firefox).
Bug: T171600
Change-Id: Iaacf24f7bef40a24230fcfa08e15bab31b1587c0
This stops the welcome dialog from being displayed repeatedly if the user
edits the article multiple times in the same pageload.
Bug: T170983
Change-Id: I8cc5990e9acb1ac09a2d6dd95eef8042c70088c7
Any MW target may want to get a wikitext fragment, not just
ArticleTargets. Requires us to move refreshEditToken up as well.
Change-Id: I27d30e20fefd5ba266d3d8e5f99383e9b4d4993a
* Fix focus and resize/scroll into view after the
captcha has loaded (so after the image has loaded
for FancyCaptch).
* Add margin between input and captcha
* Enable enter-to-submit on captch input field.
* Unify code for simple/math/questy and correctly
render math as HTML (by looking at the mime type)
Change-Id: I10433cefbfea8569674c120dde5b489570e20966
Sites like to customize 'readonlywarning' with things that we can't parse.
Instead, use 'apierror-readonly'. The old message is still shown in edit
notices.
Bug: T163455
Change-Id: I592accde17b256ecee27820df12d9d312499f8f7
If we retry and get another 'badtoken' error, something is very wrong,
and trying again and again is probably pointless. This behavior also
matches how mw.Api#postWithToken handles bad tokens.
Bug: T163493
Change-Id: I488fd7e74e37922044491695d6c9025a45531281
* Pass a wikitext promise, instead of wikitext
* Handle writing of content to the dialog from within
the dialog.
* Handle diff errors within the dialog.
* Never disable the 'Return to save form' (approve) button
* Remove redundant messages
Change-Id: Ibd76e8951998f751abfb4f407682202c2f73ac7e
This will be required later when we have to fetch the original
document from the server before running a visual diff.
Change-Id: I351688f4d1fec892bc297f40c209939cbb2ccf95
Provide a utility funcition in ve.init.mw.LinkCache to do this.
Also use this in ve.ce.MWTransclusionNode/ve.ui.MWPreviewElement, and
introduce to ve.ce.MWExtenionNode
Bug: T73900
Bug: T153535
Change-Id: Ieb9a0274b8c5ae1932c431546f09d18000fa6dd9
Stops us including "[edit]" in the summary when people have marked whole
headings for translation.
Bug: T160911
Change-Id: I906398e6bf45433d904795847f59b5bf0148092f
Distinguish between the initial summary state, and a value stored from the
summary when switching modes. This lets us avoid overwriting a stored value
when section-editing, or assuming a stored value after a switch was never
edited.
Bug: T159686
Change-Id: Ie7640538140a14bbafd539b3a45928f5c55cf804
Switching modes recreates the toolbar, so if someone has already edited the
save summary it shouldn't update the initialEditSummary to that.
Bug: T159686
Change-Id: I4109442853916bebae2bce804fcd6777e3eb6d34
Refactor saveFail's badtoken handling out so it can be reused by
getWikitextFragment.
Bug: T156991
Change-Id: I686cddb5be4484211fa69640044db1bc34eacefc
This is just dead code. We never call `.showMessage( 'captcha', ... )`
(the CAPTCHA is shown in the 'api-save-error' message).
Change-Id: I48f51e89d5b366384d184e2ed505be9e7b8f3401
Refactor save dialog setup so logic for canPreview/canReview
is external and passed in.
'Show preview' will show in the VE command help dialog until
I56c1036e6 is merged in core.
Bug: T149914
Change-Id: Id718ad622be43c03df61d12b8688d53462c59f36
