This was a regression that occurred when the toolbar was refactored
recently. The correct and previous behavior was if the cursor is in a
location where the context would show an inspector tool, that inspector
tool should be active in the toolbar.
Change-Id: I8ac2b1bd21b843db30e3e9f951702378007e139a
The generation promise can get resolved (e.g. AJAX request can complete)
after the node has been detached. In that case accessing this.model.doc
will fail, so check for this in doneGenerating().
Also attempt to abort the pending promise on teardown.
Bug: 56649
Change-Id: Ia55f1c2c8dc3a3619c0b50795e50fcae4bc6471f
Previously was failing for two reasons:
1. FF requires the form to be attached before submitting
2. options.watch failed because of FF's annoying Object.prototype.watch
Bug: 56767
Change-Id: I7b3d349f057f5b87f823ce788b4143f817af5303
Syntax highlight editor shouldn't rely on GUI language directionality
but always allow for LTR text editing.
Bug: 56780
Change-Id: Iae7f9eee20ffb9a003830503865458918f5e1df3
Changes:
* Cleanup the window API to use more consistent and intuitive methods - we
now use initialize/setup/teardown instead of
initialize/onSetup/onOpen/onClose as methods which are overridden, and
use open/close methods to control the window
* Change events around to have opening/open and closing/close events which
act as before/after points during the opening/closing process
* Make WindowSet and Context respond to windows being opened, rather than
opening them directly
* Fix a LinkInspector creation mode bug where the initial text doesn't get
reset
* Move inspector, a VisualEditor concept, back to VE
* Cleanup naming of SurfaceDialog, SurfaceToolbar, etc. to use shorter
names, they were given Surface* names when the generic ones were also in
VE, but now the generic ones are in OO, so they can return to their
original names
Change-Id: I82c4fed8bcb3fb5630938c8bc4dd9b2d5f1a8c1d
In general, the direction of the MWExtensionInspector textarea
should be dependent on the directionality of the node it is editing.
The only exceptions are <hiero> and <math> that need to have their
textarea LTR always; these two inspectors' directionality definition
is overridden in their onOpen() method.
Bug: 56779
Change-Id: Iac5c1c3bf2c61b9fa36c9588c1734c91ca4305c4
Grouping multiple $out->getTitle()->getPageLanguage() calls
and updating its use instead of the global $wgContLang
Change-Id: I1bc0e83cbd31a95b1716665314e082d5ed9113ea
Split the current icons to rtl and ltr versions.
Rename all the current mentions of beta icons to ltr and rtl,
even those that don't yet exist or are commented out.
Change-Id: I96be20515cc9d84d2d71ac7e65d97d72d96636b0
Underline is particularly important as CE will apply underline
formatting automatically when you press Ctrl+U but the
SurfaceObserver will not notice it, leading to inconsistency
between the view and the model.
For sub/superscript I've used the Google Docs key mappings as these
appear to have the fewest conflicts with existing browser shortcuts
and there isn't much consistency between desktop clients anyway
(Word and Open/LibreOffice use completely different shortcuts).
Bonus: reordered command lists to be consistent with UI layout.
Change-Id: I92998e42f9bcfb932d44e8f483811efd538e5981
Renamed events:
* performance.domLoad --> performance.system.domLoad
* performance.domSave --> performance.system.domSave
New events:
* performance.system.activation: total load time
* performance.system.domDiff: timing of paction=diff; like .domSave
* performance.system.domSerialize: timing of paction=serialize; like .domSave
* behavior.lastTransactionTillSaveDialogOpen: time from last transaction
until user opened save dialog
* behavior.saveDialogOpenTillSave: time from save dialog opening to user
clicking save
* behavior.saveDialogOpenTillReview: time from save dialog opening to user
clicking review (skipped when a cached diff is shown)
* behavior.saveDialogClose: when user closes save dialog; duration is time
* performance.user.saveComplete: time from user clicking save to successful
save completion; 'retries' indicates # of badtoken retries
* performance.user.saveError.*: time from user clicking save to failure;
'retries' indicates # of badtoken retries
** performance.user.saveError.abusefilter
** performance.user.saveError.badtoken: token was bad and we prompted the user
** performance.user.saveError.captcha
** performance.user.saveError.editconflict
** performance.user.saveError.empty
** performance.user.saveError.spamblacklist
** performance.user.saveError.unknown
* performance.user.reviewComplete: time from user clicking review to diff showing
* performance.user.reviewError: time from user clicking review to diff failure
since dialog was opened
Change-Id: I9815fa637d34c766c163e181d2f9527d3f32a7c3
When the editor is focused, the selection goes back to the start of
the document. This was remedied in the .focus() method, but not in
response to native focus events, so when external code blurred then
refocused the editor, the selection would move to the top.
This broke section editing on wikis where ULS is installed: the
selection would be initialized at the start of the section, but then
ULS would load and blur the documentNode (by focusing the pasteTarget)
and then focus it again, so the selection would move to the top.
Instead of restoring the selection only in .focus(), restore it in
response to focus events on the documentNode. When this is done,
saving and restoring the scrollTop is no longer needed.
Bug: 56651
Change-Id: I14700174ee092f9b208215d31a7d1871078a89bf
