Same random finds while working on something else. I carefully
checked and made sure these methods are actually called without the
optional parameter.
Change-Id: Iab36fd130258322985b5d6e7f8e1f7b4ee235ba2
These are only needed when we need to access a specific `this` from
within another `function () {}` context. This is not the case in the
situations here.
This is split from Ibf25d7e to make it smaller and easier to argue
about.
Change-Id: Ide1476de91fc343aa992ad92a1321d3a38b06dd0
This ensures the full loading sequence is shown when the
user opens VE using history navigation.
Bug: T301843
Change-Id: Ia7a641c8bd5a036f23c9da94bc539d8cf66c5021
Previously, a toolbar with the extra tool could be shown for a moment
while the editor was loading.
Bug: T301626
Change-Id: I7f5d01ef6e64ef85141a38a236fe2a1d1ada00e8
When the editor is loading, and the browser window is narrow enough
that we should use the narrow toolbar, the wide toolbar would appear
for a moment. It was particularly jarring when it caused it to wrap
over two lines.
Bug: T301626
Change-Id: I551a66edab40235c4a26751eed163b5b30ef698f
* Pass 'noPrompt' to #tryTeardown
* #loadFail gets triggered by the data promise being aborted,
so if 'activating' has been cleared at this point, don't
prompt about there being load error.
* Retry/cancel dialog assumed you were coming from a wikitext
editor. Rewrite the logic to handle teardown the target if
the user is coming from read mode.
Change-Id: If9e5d1fbf00f8359f4d06fe7fc3064cc7e349bc9
Previous attempt in 005a8d24ef,
reverted in 3c1d167b33.
The deduplicateStyles() function lacked a check for fosterable
positions, which caused T299767. This is now fixed.
Also added tests.
Bug: T287675
Bug: T299251
Change-Id: I0d22be9b66d26d09373cee63dd6ce52c1659e62d
We introduced these methods in Idc0cccbe but didn't update this
logic in MW.
This prevents focus being put inside an image caption if the section
starts with a block image.
Change-Id: I4cc1a116c1dcc8e1c642359ea768b6f5265a061b
Parsing it in the RL module caused the module cache key to depend
on the parse, which is slow and makes ResourceLoader sad. The usual
approach for solving this (I206bb05d28) can't be used, because of
how EditPage generates this message.
Bonus #1:
Generate the message for the correct page title. MediaWiki allows
customizing it per-namespace or even per-title, which we haven't
supported before.
Bonus #2:
Pass the context for message localisation (depends on I5f7c77970d).
EditPage::getCopyrightWarning() was parsing messages without the
interface flag, causing some needless processing elsewhere.
Depends-On: I5f7c77970d0525c0ff394f8bd72c69dcb5d00623
Bug: T298822
Change-Id: Iaa626f0e6379a5a370f9c465cea8528bb5bde7f7
* Find the first section below the top of the viewport
(usually visible) and measure its offset.
* After loading the editor, ensure this heading is still
at the same position on the page.
Bug: T296910
Change-Id: I9a05ea74ba3c19a4a91ddc1bc0afe311851c53e6
* Use this.getElementWindow
* Use this.surface.padding to avoid race condition
when the toolbar hasn't fully rendered yet.
Change-Id: I055b1d9458d73e435ede6096941a3e72c9c1ce74
In case the save is triggered without the save dialog (for example, when a null edit is made during suggested edits task in GrowthExperiments)
Bug: T298552
Change-Id: Id49b967cfa52d33848e9c911086000fa4501fa7f
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
* Make ve.ce.MWBlockImageNode autofocus=false, remove
unused transition property
* Remove ignoreChildren from ve.dm.MWBlockImageNode
based on new definition
* Remove tests which assert that deleting in a list next
to a block image always de-indents. If this is desired
behaviour it should be fixed without reference to
ignoreChildren.
Bug: T295905
Depends-On: Idc0cccbe73d1b49d07b60c14a192a40f47d64608
Change-Id: Ib79a070f5d36dbe7742fa0760f8cdf55fe3046ed
Load errors are already handled in the MobileFrontend part of the
mobile visual editor, by this code:
66c55573e5/src/mobile.init/editor.js (L375-L387)
// Wait for the data to load before we show the editor overlay
overlay.getLoadingPromise().then( function () {
...
}, function ( error, apiResponse ) {
// Could not load the editor.
(1) overlayManager.router.back();
if ( error.show ) {
// Probably a blockMessageDrawer returned because the user is blocked.
document.body.appendChild( error.$el[ 0 ] );
error.show();
} else if ( apiResponse ) {
(2) mw.notify( editorOptions.api.getErrorMessage( apiResponse ) );
} else {
mw.notify( mw.msg( 'mobile-frontend-editor-error-loading' ) );
}
} );
Compared to our code:
ve.init.mw.MobileArticleTarget.prototype.loadFail = function ( code, errorDetails ) {
...
(1) this.overlay.onExitClick( $.Event() );
(2) mw.notify( this.extractErrorMessages( errorDetails ) );
};
The lines marked with (1) and (2) do basically the same thing. And
the function parameters "error, apiResponse" and "code, errorDetails"
are actually the same objects, just with confusingly different names.
This causes the popup with error message to appears twice (although it
isn't too obvious, since the two popups appear in the same place, so
only one is visible), and also causes bogus data to be sent in event
logging (T237063).
Bug: T237063
Change-Id: I7fe7a944707fe585251ce9e16bbb78ccd123a7ed
I tried to review all of them. Some of the changes I did:
* Make sure the `config` parameter is not marked as optional
when it is not.
* Make sure default values are mentioned.
* List individual `@cfg` options when it makes sense.
Note I don't list all options a class could accept (e.g. via all
its parent classes and mixins). That's too much. Instead I checked
how a class is actually used and list only these options.
Even then I don't list everything, e.g. unspecific options
like "classes" that can be used pretty much everywhere.
Change-Id: Idf4fbe1dc3608ace277df9e385f2f140df3a2f50
If editor loading was aborted while the surface was already being set up,
this code would cause the following exception:
Uncaught TypeError: Cannot read property 'tools' of null
Introduced in c02c529537 (2017) because
our coding conventions at the time demanded that all `var` statements
must appear at the beginning of a function.
Bug: T287487
Change-Id: Id657d6f1e1189c17ede25362f145bb7b10f441db
