This is a more radical change, compared to the previous patch.
I will post more detailled explanations as comments on Gerrit.
Change-Id: I6909b3f0b2c153b7ee9995441e995ffa793eab40
This is done for a lot of the elements in this class. They are trivial
jQuery elements instead of OOUI widgets. While we usually want to use
OOUI widgets, this is different in this case. Think of a template with
1000 parameters.
Bug: T291284
Change-Id: Ie1960ee706dca17aa4963c23a2e89c1cfff106f9
The event "focusTemplateParameterById" targets the right side of the
dialog. The input field for the parameter should be focussed. This
doesn't make any sense when the parameter was just removed (i.e.
unselected).
Change-Id: Ie75b1edaebe9d0444b98e66cb56a5c7774393bea
Preserve the place of annotation meta tags; adds information for the
users about annotation and, if necessary, annotation range extension.
The messages and individual handling of annotations for the annotation
range can be defined by the extensions: see I0b58a418 for an example
of how that can look like.
The structure of this patch closely follows the one from I104e7abbd
(handling of <noinclude> et al.).
Bug: T261181
Change-Id: I39029e4a63d22b37107edec066006557bcff34bf
It should be possible for extensions/skins to trigger the click event
It should be possible to do $('#ca-edit').trigger('click') so that
Vector's sticky header can trigger the VisualEditor.
Bug: T293159
Change-Id: I58625ffca982edfbc4cdcb14a666d79093e1b89d
Removing the selected item causes StackLayout to select (and scroll
to) its first item. To prevent this, we preemptively unselect.
Note that even when an unselected item is removed, StackLayout still
clears the selection, so this patch doesn't lose any useful
behaviors.
Fix should be pushed down into OOUI, unless there's a use case where
we want to select the first item?
Bug: T293635
Change-Id: I0c1fddfa32b76621a9f1328c8173f0158386aee8
The signature of createInvisibleIcon was changed but this
was never updated.
This fixes invisible template renderings inside previews, e.g.
inside the reference context item for:
<ref>{{InvisibleTemplate}} Content</ref>
Change-Id: I3d1b7a177408032957ac3fa8ead813438aa6bda7
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
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
I moved some code around and found that quite a lot of code wants to
know:
* Is the length of this transclusion exactly 1?
* I need that 1st part.
There is more that can potentially moved from the dialog to the model.
But I don't want to make this patch to big.
Bug: T292371
Change-Id: Ia94ed0450d04dd97c4c41f5bf7c266f9a534e821
This includes some moving of code. These helper functions seem to make
more sense in the TemplateDialog class.
Bug: T292371
Change-Id: I004405bab60a569b084f9083fefa41f44f9a5561
I hope this code is a little cleaner. This patch doesn't change how
the dialog behaves.
Bug: T292210
Change-Id: I237812b3404437948eb76d8b36dcca2a4c688d6d
This method does not only select a "part", i.e. a top-level item like
a template. It also selects sub-items like template parameters. The
new name reflects this better.
Change-Id: I51a8ddbd05b283248afba5a623cc52da7b2434f5
The TemplateData extension is not limited to the Template: namespace.
And even if pages outside of the Template: namespace typically don't
have TemplateData information, the API is still able to automatically
extract parameter information from every page.
Or:
It's rare that a page outside of the Template: namespace is used as
a template. But if it is, this is not a mistake. The code here in
VisualEditor should not try to be "more clever" than the user is. If
this is what the user want's to do, let's not block them.
Bug: T291883
Change-Id: Iaf3fd5530b74fab7cedfc85ce04c8c40632df11f
The feature set is (almost) fully covered by other tests, notably
the tests for the …OutlinePartWidget base class and the other two
subclasses.
The only bit that's not covered any more is the
"visualeditor-dialog-transclusion-wikitext" message. But that's
super minor and not worth a separate QUnit test.
Bug: T291157
Change-Id: I574f9cff0baf3dff885094769c124a9e05a1d1c8
The code that uses it is commented out
Bug: T291729
Follow-up: I7af2bc91524e832555b66f090a671672cd14f294
Change-Id: I4cceb9ca83a2274fa93783af3608b9486b773522
It's not only used as an event handler, but called as an ordinary
method as well. Let the name reflect this better.
Change-Id: Ie5a0d9c4cd072063a164886f18d0859327b3f267
Note this patch is somewhat incomplete. The feature fully works and
I would like to see this patch merged as it is. But whenever you
press one of the keys the focus is stolen by some element on the
right side of the dialog. This makes it impossible to e.g. press
Ctrl+Shift+Down multiple times. The idea is to work on this in the
next patch.
Bug: T290262
Change-Id: Ic67f2a696c94f1e5c71134d681161221aecbfdf6
Reasserts scroll and highlighting when toggling the sidebar, in the
case that the other panel is hidden (narrow-view mode).
FIXME: Doesn't reassert focus because the page.focus() and
bookletLayout.focus() methods don't seem to work, maybe the bug is
especially prominent when the item to focus was already marked
active.
FIXME: Stopped working for right-to-left sync on wikitext elements.
This is a less common use case and can be addressed in follow-up.
Bug: T290975
Change-Id: I94f5709e810c63ee5fd7729a192ac7b92686b88f
… obviously only to methods that are meant to be private, i.e.
only called from within the class (and possibly tests).
Change-Id: I581558078dc7210abac5f5724f71316ac45745e6
The .onUpdateOutlineControlButtons() method doesn't describe what it
actually does. This issue was introduced in I9c5478a. (Intentionally,
to not make the patch to complicated.) Let's continue to rename
things to be a) unique and b) honest about what they do.
This is an alternative to I8d98e61.
Bug: T289043
Change-Id: I4d52ffa6e9e5df2025a0c33031c1517bcb421279
