New changes:
e1ada5fd8 Localisation updates from https://translatewiki.net.
4373b0a6e Create new stacking context for diffElement
Bug: T292491
Change-Id: I0399a57443404e20066c3292b78fe01f6947faf3
After filtering the PHP array to only include the ids
of namespaces with subpages enabled, add an array_values()
call so that the ids are again indexed numerically beginning
from 0, which is needed for the array to be passed to the
JavaScript as an array rather than an object.
Bug: T293310
Follow-up: Ia0ecac71721eceed52cc90f39ecc560bdf1b7f9b
Change-Id: I45bb281314caf5da0b7836829eb44f858836566f
New changes:
026d0cb4f Localisation updates from https://translatewiki.net.
f16f2179c Never rebuild above the attachedRoot
78bedf8be ElementLinearData tests: Refactor for loops
aed112aa8 Follow-up Ia593dad856: Use set data when changing character in sanitize
Bug: T293254
Change-Id: Ic5d5c1b77ae86eb18ebcb250c4b9c0ed64ccba6d
This reverts commit 2c75722ff1.
Reason for revert: Creates too much warning spam (>50) which makes
errors hard to spot. Most of these should be fixed before enforcing
the rule.
Change-Id: I8a785ec73d3429d4681d5c965a0efdbf0c86893d
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
New changes:
8161c0a6e Localisation updates from https://translatewiki.net.
c5e396884 Add precision on matching order in ve.dm.ModelRegistry doc comments
82bcc8562 build: Updating ansi-regex to 5.0.1
9b2c9b97a Localisation updates from https://translatewiki.net.
5805b83ba Move eslintrc config into sub-folders
Change-Id: I9baaa2193465a0a852baf0fba59404381d8fe292
When I type e.g. "subst:example" as the template name, we made this
work as the user would expect: the template named "Example" is found
and it's TemplateData documentation used. But the dialog title shows
"Subst:example". Note the uppercase "S". It means this string is
parsed as a title, including the "subst:". This is confusing. Just
show the template name.
Change-Id: I9817786991a8379cf48b0a664aef1413abddee2d
Some cleanup to improve readability and reduce the amount of code.
Relevant bits:
* One method name was wrong. It can actually return parameter ids,
not only top-level part ids.
* I got rid of some fail-safe checks that are never needed or moved
them to a more central place.
Change-Id: I08f2ad7bc7d3f985d6189dff170dda554f3d37c2
This patch fixes two issues:
* The bottom corner of the new sidebar was never correct because of
a `padding: 2px` that was introduced later, but never compensated
for.
* The moment the toolbar is shown it's not a single-template dialog
any more. This implies minor style changes.
Bug: T290262
Bug: T292727
Change-Id: I08da73880c469085994ee4beb3fcdd973f80ae11
The idea of this piece of code is to make sure both sides of the
dialog show the same element. But it doesn't make sense to force the
*header* of a template into view when I clicked on a *parameter*.
Bug: T292718
Change-Id: I9945f8e54c856152f05bf717e43468ab5ab24d2f
I run into this in some local test. There are two reasons this code
can be reached:
* When a wiki doesn't have the TemplateData extension, the
additional API call from line #154 will fail. But the original
search query succeeded. We have the `originalResponse` and can
return it. This makes the code behave as if the additional
TemplateData API call was never done.
* But what if the original search query failed? We still end in
line #183 – as we should. But this time it can't return anything
but undefined. This will be considered a valid, successful API
response. But it isn't.
There might be a better way to clean up this chain of promises.
This is the smallest fix I found.
Change-Id: I02d3d053156da222ee424382007621f314777015
Instead of using an object mapping namespace ids to if they have
subpages enabled or not, pass an array of the namespaces where
subpages are enabled, reducing the size of the configuration that
gets loaded on all requests. Only requires a minor update to the
JavaScript that uses the value (check for array index instead of
object value).
Bug: T291729
Change-Id: Ia0ecac71721eceed52cc90f39ecc560bdf1b7f9b
