As of 46f40dc, we've split the VisualEditor API backend and the
part containing the parsefragment method no longer needs
an edit token.
This gets rid of the warning that started appearing after 46f40dc:
{
"warnings":{"main":{"*":"Unrecognized parameter: 'token'"}},
"visualeditor":{"result":"success","content":"<p>foo\n</p>"}
}
Change-Id: I36f79fa8ae48cdbec1b3506953418561ef2ff828
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
The resizing handles under ResizableNode are created in the location of the image
but if the page is edited and the image moves relative to the document, the handles
remained where the image was previously and not where its updated location is at.
This code fixes that bug by changing the CE event listening to the model's 'transact'
instead of 'history', and clears the cached offset when a 'transact' event happens.
Change-Id: Id0e4296dd89b24839ba68a534ca77d73c23b7434
When the ListToolGroup in the toolbar (the "More" section) is scrolled
down such that the top tool is partly obscured, and you hover over the
bottom half of the "More" button, the top tool displays a hover effect
and using the scroll wheel will scroll the list rather than the page.
This is because the list has a box-shadow that's 1em tall, and the
height of the "More" button is 2em. And in Chrome, pointer events
"work" even in the box-shadow area. Roan reported the Chrome bug at
https://code.google.com/p/chromium/issues/detail?id=314291
This change works around the bug by making the tools in the list
inline-block instead of block; for some reason the bug only affects
block elements.
Change-Id: I4ea3f41c91d0ff5d5cc150fe8acc3427f0ab5f3a
