Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
* Fix incorrect use of .append() instead of .text() (which was causing
some l10n messages to be treated as raw HTML)
* Avoid escaping and parsing HTML several times when plain text was
intended
* Remove some unused options and variables
Follow-up to 839b64d882.
Change-Id: I124257c73fe09713afefccdec8e90200e6ae433d
The "Add parameter" page always starts collapsed. Even if a template
doesn't contain anything but this. But most of the content isn't
visible, unless the user presses the button. It's not only a lot of
content, it's also rather expensive, including .parseDom(),
LinkCache.styleElement(), and ve.targetLinksToNewWindow(). This adds
up in large multi-part transclusions. In an example with 200 parts
the total blocking time goes down from 2.9s to 2.4s. Which means this
is not a major bottleneck, but still worth it.
Bug: T296335
Change-Id: Ieab9fd35d145142b04d2267d8e5a2e10a4c02784
* 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
These pieces are only relevant when the new "inlineDescription"
feature is enabled. In other words: This can't have an effect on
the old dialog.
The 2.5em left and right are from an old styling when the
parameter pages have been indented.
Change-Id: I022b0dd94ee66f7de114c055c3f453317a7f6131
This sorting algorithm was introduced via Ic6bc348 (T274544). Note
there is no index parameter in the .onReplacePart() handler at this
point. When a part was moved, it was removed and simply appended
to the end. The additional sorting was needed to move it back to the
correct position.
This changed a few days later via Iafe29f1. There is now an index
parameter. The .onReplacePart() handler does the same as before, but
puts the part at the correct position right away. The additional
sorting is pointless since then.
The removed code alone is responsible for 1/3 of the total blocking
time when the template dialog opens.
Bug: T296335
Change-Id: I6c3fa70b532d34cd29d59c3b48ab81ebf608d548
onReplacePart is being called when templates are being moved up or down.
To prevent that the multipart message gets moved around passively e.g.
by one element being added above it, this patch adds it to the top after each movement.
Bug: T292829
Change-Id: I946c9bc4ba5e1d261aefbb28a8c642bb58964842
We forgot change the way that message is build while adding the link
in 07f105fd7. Now it gets parsed correctly and the link will open in
a new tab.
Bug: T284985
Change-Id: I1ed9dfdafd08d08c5aff45f4b74c540b35ec14a1
This is only relevant with the old design. It's only noticable when
a field shows all 3 action icons: info, raw wikitext mode, and
trashcan. The last icon can wrap to the next line when the screen
is very narrow.
I tried to apply nowrap, but this causes other style issues.
Removing the arbitrary width allows the action container to be
as wide as it needs to be. I can't tell why this restriction was
there. It is in no way necessary, as far as I can see. I can only
guess it's a temporary artifact from when the dialog was designed.
Bug: T296730
Change-Id: I77129ccc3afe002ba697b1787b41d0a388d5f4b8
This does have a significant impact on the performance of the
template dialog. Not only on construction time, but also because
MWExpandableContentElement objects do some quite expensive
.updateSize() calculations the moment they become visible.
I profiled a template with (only) 200 undocumented parameters.
Construction time goes down from ~600ms to ~520ms. The mentioned
.updateSize() runtime goes down from ~300ms to ~10ms.
Bug: T296335
Change-Id: I280f814e722b299aae0ec6a5a2fa59292e3e5887
This doesn't have much of an impact on performance according to my
profiling. But I think it's worth it nevertheless. The idea is to
skip that <div> entirely when it's empty.
Bug: T296335
Change-Id: Id155725fbc2e3453acc1cdcabfdc2d687285d694
In OOUI the close button is always on the left side. See
https://doc.wikimedia.org/oojs-ui/master/demos/?page=dialogs&theme=wikimediaui&direction=ltr&platform=desktop
The CSS hack to move it to the other side doesn't work and must be
removed. You can see the problem the moment the text is longer (which
can easily happen in translated versions).
I tried to come up with a more official way to move the button to the
other side, but gave up. One way is to replace the existing
flags: [ 'safe', 'close' ]
with:
flags: [ 'primary', 'close' ],
framed: false
But this causes other style problems. Let's remove the bogus CSS
first and possibly try again in a later patch.
Bug: T294839
Change-Id: Ia6ddefd99e4a03a87b0450ab94712ff19bb268e4
There was a remaining issue when the window was made very narrow in
desktop mode (smaller than 500px). This patch doesn't aim to really
"fix" the dialog's design in this case. The goal is to make the popup
window appear less broken, so the text can stil be read and the
buttons clicked. That's all.
This patch should not have any effect in:
a) mobile mode,
b) desktop mode when the window is wider than 500px.
Bug: T294839
Change-Id: I3171dbb991533b91eaadba63b78d0ff40aa486dc
Same as I980b72c, but with another shortcut. Again. We tried
Ctrl+Shift+X before (conflicts with RTL feature in VisualEditor), as
well as Ctrl+Alt+D (conflicts with "hide all windows" incUbuntu).
Bug: T294905
Change-Id: Iae7ba759fcd7c107ef586bd5d9ae3cdbe445cedc
Allows setting aria labels and descriptions on elements in a
convinient way. I did not use the the .mixin. convention here for
because there's already another mixin in that folder that's also
not having .mixin. as part of its name. And then there's also no
no need to open up that extra namespace here.
If we move this upstream at some point this can be changed though.
Bug: T291284
Change-Id: I1b3d40400d539f851f13719e16ced200968a7f92
When changing the source in the described-by attributes the screen
reader will read the text of the new source when the status changes.
Just changing the text within the elements holding the descriptions
does not work.
Bug: T291284
Change-Id: I31cc3061cf6c1f699babe41e99e0711f0eb03646
Screen readers will read the collapsed content despite the fact that
it is not visible due to the way it is hidden with CSS. The more button
makes no sense for these users and is probably more confusing than
helpfull.
Bug: T291277
Change-Id: I71888d8b9565d5ee85c5e7a48965e9e9a76eb984
ARIA-selected only works on specific elements/roles. I tried several
combinations here, the most fitting seemed to be the option role, but
that role did not work very well in FF with NVDA. It also should only
be used as direct child to a listbox e.g. with several children.
The next role that's working with ARIA-selected that seemed fitting
is the gridcell. It's still a bit hacky but works well in IE and FF
with NVDA. I suspect that that's pretty good coverage already then.
Bug: T291284
Change-Id: I85c865b0ab12d3923e472e5f36b5c07b7c722180
The following keyboard combinations are now supported on MacOS:
1) CMD + DELETE
2) CMD + DEL
3) CMD + FN + DELETE
(1) for keyboards without a DEL key use DELETE/BACKSPACE
(2) for keyboards with a DEL key
(3) FN + DELETE is a built-in an alias for DEL
Bug: T294519
Change-Id: I896837954b2f0b36a25484080e57d929a5abf774
For example, the Citoid extension adds a "change reference type"
button which should be visible when editing a citation template.
TODO: Decide whether we want to hide the "hide options" button in
this case. This should be handled in a separate patch and possibly
in a follow-up phase, it requires deeper changes to the logic.
Bug: T294351
Change-Id: I1c6c322fe48044d7e726bf20ba7cd2eda422cd8b
I can't reproduce this error, but I feel better having this safe
guard in place. In theory it's possible to trigger resize events
before the TransclusionModel is initialized.
Change-Id: I4bbac0f73873813629ff854ee728465c6e2a4ba7
I6909b3f0b2c153b7ee9995441e995ffa793eab40 was rebased, but
I0226ca7d39e04a69617c0d8a5d3c293cfc9e0709 was merged in the meantime.
Bug: T293202
Change-Id: I3cfec9ebc135eaf998a0982f458cfe75bfb2f01c
We're mainly interested in the layout of a button here. From a
semantic perspective this is just a header to an editable area
and not a button.
Bug: T291284
Change-Id: I683cca2e7d6549e652bd03ae1e46f4eff8c07d0a
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
