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
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
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
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
I can't really tell what insight we get from the word "container".
Every widget is a "container" in some sense, isn't it?
This widget is just _the_ outline, I would argue.
Other suggestions?
Change-Id: I1fb27ee58c1a3dd790022504e978198dadf7ea02
This prevents multiple highlighting, which was possible to achieve by clicking
sequentially in the input fields of two parameters from different templates.
Change-Id: I404936f1569ab544b693a9bc6921381636ea8f40
This is bad for multi-template transclusions, where we focus the
first parameter of each template ending with the last. It's also
inconsistent, we don't do the same for wikitext chunks.
Change-Id: I720ce1a380a6f4a8618c3608b63557df5fb50393
This was damaging the UX by causing the first parameter to be marked
as selected, but without reliably focusing it. For example, loading
a wikitext-template-wikitext multi-part transclusion would cause the
initial focus be given to the documentation link in the template
content header. After this patch, the focus will be at the top of
the page and tab will run down window functions and then through the
sidebar.
Change-Id: I84131870ae3887dcae74d91d68c5984d1dbffd85
The weird auto-scroll feature is described in T289043#7297679.
This also fixes T291381 different than I393a2b1. Only one of the
patches should be merged.
Bug: T289043
Bug: T291381
Change-Id: I70d87f12fd68001e880510fb6c38d7c419d64b15
AddPart in the resetDialog also triggers replace part
so this call could be removed there.
Bug: T291365
Change-Id: Id6c0f5bf3aaece45da37ffab75a4d99c113944f6
This is mostly re-arranging existing code. Actual changes made:
* Remove the message that claims a template can't exist. We can't
really know this.
* Instead show the message about "modifiers" in cases where curly
braces and other wikitext syntax is involved.
Bug: T290140
Change-Id: I713d7f54cad2510f9a02c113600980cba8c3e58b
The titles in the link cache do not include subst: anymore so to see
if these pages exist we need to use the same link title used in the
query.
Bug: T290140
Change-Id: I18de81e0bf46212c2199a948f7ca89182aa19eff
This code was introduced in I8fafee6. I can't tell any more what
the "bug" mentioned in the commit message was. Let's get rid of the
duplicate code path, see if we run into regressions and deal with
them one by one. That's much easier to handle than keeping this
confusing code path around.
Note this "focusin" event handler was actually re-implementing
parts of the upstream BookletLayout, namely
OO.ui.BookletLayout.onStackLayoutFocus().
Bug: T289043
Bug: T291381
Change-Id: Ib386ae6efec08465122f0e8ee81cd6dc9a2d337a
Note there is still an issue with the upstream
OO.ui.BookletLayout.selectFirstSelectablePage() method stealing
the focus in some situations when you press space. Still this patch
already improves the situation. Pressing space on both top-level
template elements as well as parameters should scroll the thing into
view, but keep the focus in the sidebar. This was just not happening
at all.
Make sure to use a very long multi-part template to test this.
Bug: T289043
Change-Id: I9c5478a04b14b94ccd5d00480d48a7d59b4e0c37
We broke something with the change I166b971. When we renamed that
method it started to override (and therefor disable) the method
with the same name from the base class.
I decided to move all code in the subclass for the moment. It might
be misplaced there (note how almost all code related to the new
sidebar is in the base class). But this is cleanup work for later.
Bug: T289043
Bug: T291151
Change-Id: Id255585e78967eee0f72c27727cd23211674923c
The most basic fix. The "outlined" flag is set to false for the
cite dialog, in contrast to the transclusion dialog. It's always
true for the transclusion dialog. Note it doesn't mean the sidebar
is visible, but specifies if a sidebar is created in the first
place.
Bug: T291241
Change-Id: I5a8b538949e9fd0b8e85a6a91ca2420ef72e4612
We removed this line of code in a recent patch, but it turns out
it's still necessary in at least one situation:
* Make sure you have a multi-part template where the first part is
a wikitext snippet.
* Edit the template.
* Click the very first item in the sidebar.
Nothing happens. But the text cursor should be in the wikitext
field.
Another situation:
* Put the text cursor in the first wikitext field.
* Press shift + tab. Now a button in the bottom toolbar should have
the focus.
* Click the 1st element in the sidebar. Again, nothing happens.
The extra .focus() call is redundant in many situations. But it also
doesn't hurt to repeat it. It will just re-focus the element that's
already focused.
Bug: T289043
Change-Id: Iccbe376b98a1b1e5469cd17e1c95d5d8869442d3
It was called like this because the event is literally called "set".
But it doesn't explain _what_ is set.
The new name .onBookletLayoutSetPage() already appears somewhere
else in the codebase.
Change-Id: I166b971c08f5d0fae97fc9d6244117a680f84b7c
The previous patch Id314ee8 was incomplete. The event changed.
The id in the event is not guaranteed to be a top-level partId any
more, but can be a template parameter's id.
Note: "Parameter id" and "pageName" is the same. The fact that
these ids match is how the left and the right side of the dialog
communicate.
Bug: T289043
Bug: T291151
Change-Id: I391f0f8edb96398fd33a2e0b01003013c52776da
I realised these are vital information to make the buttons at
the bottom of the template dialog behave sane. It's still
possible to focus this page, even if it doesn't have a visible
item in any of the old/new sidebars. This is when these flags
are used to decide if the up/down/remove buttons should be
enabled.
Bug: T291151
Change-Id: I6ab709b856d110bfb37daa1592c0b6a99714aa25
The OO.ui.OutlineOptionWidget class does have an .isRemovable()
state. This is how OO.ui.OutlineControlsWidget decides if the
remove button can be used.
It appears like ve.ui.MWParameterPage forgot to mark required
parameters as not removable.
This makes some oddly specific code in ve.ui.MWTransclusionDialog
obsolete. Note how this class does not contain any other code
about "required" or other flags specific to parameters.
Note that one aspect of this patch will be visible in the old
sidebar: The trashcan will be visible on required parameters, but
disabled. It was hidden before. However, this actually improves
the UX. Hiding the trashcan made the up/down buttons jump around.
This makes it unnecessary hard to hit them. It also causes visual
distraction when navigating the list of parameters.
Let's stick to the upstream OOUI behavior.
The remove button still disappears when the only element in the
dialog is the template search widget. This is clearly an
entirely different state. (Don't ask why the up/down buttons are
not hidden. It was like this before.)
Bug: T289039
Change-Id: If78881e503f19f497f1993da4e5b9b09ee538307
The separate setup method was introduced in 2014 via I7c3c133.
It appears like most of the code here was written before this
method existed. Let's update it.
* this.outlineItem is guaranteed to be set. No need for the `if`.
* The parent method is effectively abstract. There is no point in
calling it, I would argue.
* The return value is never used. I.e. this method is never
chained, and probably shouldn't.
Change-Id: Ida26ebdf09be74958936c3950ebdf6def9a69bc0
The behavior of the enter key in the new template dialog sidebar
is somewhat inconsistent. When pressing enter on the name of a
template it sometimes just doesn't work, but focuses something
else.
I realized this is because the message "The … template doesn't
yet exist." does not have a link. There is nothing to focus in
this element. The code just gives up and the selection returns
to whatever was selected before.
It works when there is a link in the template header. But this
is not even that useful.
Let's try to always focus the first parameter instead. The user
can still press Shift + Tab to focus the link to the template
page.
Bug: T289043
Change-Id: Id314ee8ebf47d387df08c7fb432094b6d8f7a3d2
The previous patch I15aa2c0 (approved by UX) was incomplete. The
required indicator was still shown, depending on the skin.
This patch also reduces the amount of generated HTML when it
doesn't have an effect anyway. At the moment an empty <span></span>
is generated for _every_ parameter in the dialog. That's potentially
hundreds. But the element is only needed for deprecated and
(in the old UI) required parameters.
A missing space is added while we touch this code anyway. The
missing whitespace between label and indicator icon is confirmed to
be a bug by UX.
Styles that are the same on all skins are moved to the .css file
that's loaded for all skins. Missing word-wrapping for overly long
template parameter names (on the right side of the dialog) is added.
The position of the indicator icon was broken on Minerva the moment
a parameter name is a bit longer. Fixed by replacing `inline-block`
with `inline`.
Bug: T290492
Change-Id: Ie346d88969cec2effaf90d328d08567ab7b7bf75
This applies in several situations. A trivial one is a parameter
that's already in use, but you uncheck it while the relevant
error message is shown. Vice versa.
Bug: T290977
Change-Id: Ia4114194a2efe34a7d51e633c776ce892cc9cb18
This patch improves the error handling for when a user tries to add
a parameter which is either an alias of a existing parameter, the
primary name of a existing aliased parameter, or a name/alias of an
existing parameter which is shown with an override label.
The error message was modified to always refer to the conflicting
parameter using the same name that is has in the sidebar.
Example: A parameter named "Parameter B" is already present in the
sidebar under its alias "B". When a user tries to add "Parameter B",
the new error message will inform the user that the parameter they
are trying to add already exists as "B".
Bug: T285869
Change-Id: I762b72b6cf14eb8ff5fcef63b4dcb70e297050de
It's impossible to use the delete button from the
OO.ui.OutlineControlsWidget to delete a parameter when the new
sidebar is active.
This partly fixes one of the issues mentioned in I97d77f4. The
delete button might stil become active for a moment (not fixed
yet), but doesn't stay active forever any more with this fix
in place.
Apparently this also makes another workaround obsolete.
Change-Id: I0bca310772c26149170af23ff8e5505c3ce4adf4
There is no point in firing this event when noting changed.
This should reduce flickering and some of the issues described
in I97d77f4.
Change-Id: I7c387889a4a33dac5053cec11a0641d358020b56
This just copies the colors from the old sidebar.
* When hovering with the mouse (without click/press) the background
is gray, and the text black. Relevant for readability via WCAG
AAA.
* On click/press the background is blue (slightly darker than a
selection), and the text is dark blue as well.
As noted in
https://docs.google.com/document/d/1V0rXMPr6upNjHF9AkROx4R8IF1LDZUzrG4K6oWT08sU
Change-Id: I443045b55826ef390688b32616dfdcfdc6555eb3
As a reminder (not part of this patch): Pressing enter on the name of
a template should select it, and jump to the content area on the right.
Pressing space (that's what this patch is about) should select as well,
but not move the focus.
The best way to test the behavior is with a multi-part template.
Bug: T285323
Bug: T289043
Change-Id: I97d77f43b231696f92ba6758a6b8feac34e02e6d
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
We don't need to distinguish between these any more. Both are
"active", i.e. both focus the widget on the right side of the
dialog. Sometimes the "choose" event is fired to actually add
or remove a parameter. Sometimes it's fired, but the state of
the parameter doesn't change (for whatever reason, i.e.
because the parameter name was clicked instead of the
checkbox). There is nothing to do in this case, except for the
focus change.
Change-Id: I3c7c0c81a075ccff76eda0a4fb2aa1ac7be3cec5
* The template model fires an "add" event. Listeners don't
automatically steal the focus any more.
* Instead there is a separate "focusTemplateParameterById" event
fired from all relevant places that add a parameter.
* The "remove" doesn't steal the focus any more.
Bug: T285323
Change-Id: I93f17727524bfbcf6f11647a6c2441781337c4cc
The 'classes' property is a OOUI interface. Personally, I like
this code style better.
However. It appears like the code style in this codebase is
somewhat mixed. It looks like the top-level .$element always
uses .addClass(), while other code uses the 'classes' property.
Should we unify this?
Change-Id: I9ecd75e22d00f06ffd707f766dc9e8d748ff9a37
In JavaScript .split() behaves different, compared to PHP. In
PHP the last element contains the rest of the string. In
JavaScript the rest of the string is discarded. The limit acts
as if the array is truncated. That's why we can reduce the
number in
'foo/bar'.split( '/', 1 )[ 0 ]
to 1, as we are only interested in the element "foo".
The same code in the other class is currently not covered by a
test. But changing it accordingly should be obviously fine now.
Change-Id: I20c27d480ddb1799df9eb1e5bc119b724e80653d
When I try to click the input field, the expand/collapse button
is focused instead.
This also fixes a copy paste mistake in this class.
Change-Id: If9ab340711fbe7d88845c008360fde5df7059df0
Before, the content pane (the right half of the dialog) was moved
to the right, outside of the visible viewport. But it was still
active and could i.e. be navigated to via the tab key. Only truly
hiding it solves this issue.
Bug: T274554
Change-Id: I8925a9cca0099528aca8e98452816b5f9dd23a76
The original idea was to make the interface as narrow as
possible. However, it turns out it's better to model the
"templateParameterClick" event more closely after the "choose"
event.
This is split off to make reviewing the following patches
easier.
Change-Id: I271f576c6cd756cecfc6cb1fd64810f8da5c3575
Pure cleanup, doesn't change behavior.
Change If8da5ae85dff63c34 included in OOUI v0.42.0 tracks invisible
controls, so it's no longer necessary to maintain persistent class
variables pointing to the buttons.
Also simplify repeated logic to make it clearly exclusive.
Bug: T290554
Change-Id: If9b6404d7061999540515645fa8e50b9a21f5a21
The list of parameters should remove itself from the list of
possible tab navigation targets when it's empty.
Note there is no way to remove elements from the parameter
list. That's why we don't care about "remove" or "clear"
actions.
Change-Id: I8b1215117e0ddc94f787d173e9bea6f7567d9671
Previously, when the tranclusion dialog was being resized, there was
a specific width at which both the sidebar was collapsed and the dialog
was downsized from "larger/large" to "medium". This resulted in the
dialog switching from fullscreen to floating, since the dialog's width
breakpoint for "medium" doesn't match our width breakpoint for mobile.
If the user continued to downsize past this breakpoint, then the dialog
would eventually switch back to fullscreen resulting in this weird
behavior.
A simple way to prevent this is to avoid changing the dialog's size
at all. Since we don't support collapsing the new sidebar (unless
already in fullscreen), we can just leave the dialog at the
"larger/large" size.
Bug: T274554
Change-Id: I5460cdfb1a7ed73fe7957745ba37055c5f66dce1
This is split from patch Iebb982e to make it easier to review.
The name is rather ambiguous. Does "input" refer to the input
element? Is it triggered for every key press, i.e. when the
input changes? Or when it's submitted?
Change-Id: Iddbe3bfb9faf3561d8d71b96ffae507799827a95
Any of these characters results in bad wikitext, when we accept
it in a template parameter name.
Instead of displaying an error message we simply block the
button, as long as the input is not a valid parameter name.
Coming up with a message is not really worth it, I would
argue. Users typically don't have a reason to use any of these
characters. This is super rare. And even if, the behavior of
the widget is not hard to understand, I believe.
The same is done in ve.ui.MWParameterSearchWidget, a little
hidden in the .addResults() method.
Not yet approved by UX. Can be done in demo time.
Bug: T285869
Change-Id: I5576cdfb90411e5fdec93749f72939d31ecd9c56
E.g. avoid calling the rather expensive method multiple times
in a row, if only 1 of the results is needed.
Change-Id: Iff1d2c0892367e927303f6f45d3231e04c045cab
* Use a more specific …-top property, as this is the only thing
we need to overwrite.
* Bring some selectors in a hierarchical order that makes more
sense.
Change-Id: If36db87d83f699fe0a43ac67d439cac42cbb1fa3
* New help text for the case where TemplateData is present, whether
or not it includes a description.
* Remove help text when TemplateData is missing.
Bug: T288465
Change-Id: I0668ccae8eeb5ffffc626e3b7d24c1d7ed99bbed
I tried hard to come up with the best possible names. Some of the
criteria I used:
* Longer and more unique is better. This makes it much easier to
e.g. search for the event name.
* The term "part" should only be used for top-level parts. While
template parameters have a unique id, they are not a subclass
of …TransclusionPartModel and therefor not "parts".
* BookletLayout manages "pages" via "page names".
* The page names of top-level parts are identical with the part
id, see ve.ui.MWTemplateDialog.getPageFromPart.
* The page names of parameters are identical with the parameter
model id, see ve.ui.MWTemplateDialog.onAddParameter.
Some code knows parameter ids, but not what pages are. Other code
knows page names, but not what parameters are. The transition
currently happens in the …OutlineContainerWidget. We might want
to move this point up to the …TemplateDialog. But I would argue
this is good enough for now and can be changed later, if needed.
Bug: T285323
Change-Id: Iab2805b3203988db400b67c8d00e48905fdc53dc
I tried to memorize the cursor position in the list of
parameters. This way you could leave the list with tab, and
return to the original position with shift+tab. Unfortunately
this is not how the SelectWidget works. The moment the
highlight is gone it's gone. There is nothing that remembers
a position. We could introduce code to do this. But I feel
like this is a lot of effort for not much benefit. Also not
listed as a requirement anywhere, at the moment.
Bug: T285323
Change-Id: I8d44ba4539ec4b5535bc031accfeacd87e1886eb
This got lost in patch I20dbd2b.
Both events come from the same sidebar class. The difference
between the two is:
* selectPart is when the button representing a top-level part
is clicked.
* focusPart is when a parameter name is clicked while the
parameter is already checked.
Yes, this is confusing at the moment. Following patches will
rename, merge and split a lot of these events to be much more
self-explaining.
Bug: T285323
Change-Id: I0c6b53c93c712ff5e47c1beb5199d590cba7ab1a
We forgot to remove this in I319896a. The individual
…TransclusionOutlineParameterWidgets don't fire this event any
more. Instead this is done by the …SelectWidget.
Bug: T285323
Change-Id: I2c29e45127464785ffdc32d73b52188fcbefb7bf
Note there are currently two different code paths utilizing two
different events. The existing event handler actually changes
the selection of the top-level part in the sidebar (the
corresponding template name turns blue). The new event handler
highlights a parameter (it turns gray). This is currently
intentional (partly because of a bug in OOUI). I will try to
merge these code paths, if possible.
Please test, and if it works fine from the user's perspective,
please merge it as it is for now.
Bug: T285323
Bug: T289043
Change-Id: I8fafee68b8b7ff225c7b3c327f483f3426d8129c
Proof of concept: while flex is – well – flexible, it feels like
this should be possible with some good old block containers and
margins. It's pixel-perfect in my test.
Bug: T288465
Change-Id: I1458900fff197e08ce318398524a3cf2b6b9ee2a
- Change description text according to ticket
- Make sure link to template page opens in new tab
- Add missing placeholder text
Bug: T272487
Change-Id: Ie8189e9cb9db5908e8fc5fc8bf7ff20df5595094
This fixes a few style issues:
* The buttons that represent top-level elements have a proper
2px focus rectangle again. Back to the OOUI default.
* The list of parameters does have a 1px focus rectangle all
around. Intentionally thin because there is a 2nd level of
keyboard navigation (via cursor keys) in this element.
* All these focus rectangles look the same in Firefox. Before,
it was a thin dotted line on the parameter list.
* Parameters with long names don't wrap on a 2nd line any more.
I believe this was working before but got lost in I92e8fd2.
Bug: T285323
Change-Id: I0229b6395a64a9903335bf96349af70fb20ad047
When I press the button to expand the input field for
undocumented parameters, it needs to be focused. Otherwise I
have to click it manually all the time.
We probably forgot to list this as an acceptance criteria when
working on Ic5dcd36.
This also replaced a bit of JavaScript with CSS. I do this
mainly because I found the mixture before (one piece was
hidden via JavaScript, another via CSS) a bit confusing.
Bug: T272487
Change-Id: I0cbee63c65a37f2f1860bde007c1e5c8408ba006
This makes sure the corresponding top-leve part is selected in
the list on the left when navigating the main area on the
right.
Bug: T289043
Change-Id: Id1b398e1786c4099d5b14fe88dd21a106269096b
This comes with a few significant changes:
* A whole bunch of places in the code that focus and highlight
an element in the old sidebar consider the new sidebar now.
* Same when e.g. the toolbar at the bottom needs to know which
part is selected. This is read from the new sidebar now.
* To make this possible I had to merge the small helper class
we introduced in I7bc73cc back into the dialog.
It's helpful to understand how the event flow works:
* You click a template name. This does nothing (does not select
the element). It only triggers an event.
* The event is catched by the outer container that manages
all parts. From there all elements are unselected, and one
selected. This call is internal and should not trigger
another event.
Bug: T285323
Bug: T288827
Bug: T289043
Change-Id: I4a2d2b83cf2691423d4b0e6f4487228fa3c7b56d
This is mostly, if not exclusively visual, at the moment. The
actual state is still managed by the old sidebar.
I made the element OptionWidgets for convenience. This gives us
all the functionality we need (primarily setSelected and
isSelected), without to much clutter. However, I didn't made
the container a SelectWidget. This comes with to much stuff we
don't need at this level, e.g. cursor key navigation.
Bug: T285323
Bug: T289043
Change-Id: I20dbd2ba23ceaa9125947b25e037c0bb3c91a471
Most notably:
* Move some code snippets from the outer …TemplateWidget to
the inner …SelectWidget, without introducing new
dependencies.
* Move all knowledge about the item class
…OutlineParameterWidget class into …SelectWidget.
* Some more self-documenting method names for event handlers.
* Avoid the somewhat ambiguous variable name "checkbox" in
favor of "item". That's how it's named in the upstream OOUI
…SelectWidget.
This is extracted from the following patch Ibd94c39. The
difference is that the following patch adds a new dependency:
The …SelectWidget gets to know the template model. This patch
here contains all changes that are possible without this new
dependency.
Bug: T288827
Change-Id: I187f313c84424b28005d9276cb1356029f9ebb75
There are 2 situations:
1. Either the template name is used in a [[…]] link. In this case
we must provide the namespace. MWTemplateModel.getTitle() does
this. However, it's not a mw.Title object and therefor not really
guaranteed to be a valid title. This is fine. The worst thing
that can happen is that the link points to an error message.
But this should be entirely unreachable anyway.
2. Some messages want to display the name of the template.
Ideally without the namespace. That's what
MWTemplateSpecModel.getLabel() is for. Again this is not
guaranteed to be a valid mw.Title. But it doesn't need to. It's
only used as a label.
Change-Id: I03d0481201620a2f5c444ee32b656bcaade98aac
We should only need that label for the link. The other mechanic
would fail when editing wikitext like this:
{{{{echo|<}}|param=foo}}
Bug: T272487
Change-Id: If8d228b40bf1589181e83e8f68f3c33b4c7759c7
This also fixes a mistake in the class where we forgot to
disconnect event handlers when an element is removed from
the list. This doesn't have much of a consequence, as the
event flow is only in one direction, from the destroyed
element up. This is not possible any more.
Bug: T289560
Change-Id: I0bcc1d68c50b8cbdb033ef6692b34e2fc94e8d85
This replaces I8cf9ecd.
Significant changes:
* The …OutlineContainerWidget doesn't need to know the
BookletLayout any more. The only remaining resason to have
this dependency was some focus management. This is now done
via an event.
* Renamed an existing event to match the new one. The two
really mean and do the exact same, even if they are
triggered from two different places.
* Simplified some existing code.
* Updated documentation.
Bug: T288827
Change-Id: Ifcf2cadabf7fa4b8ecb72e3937003fab3b00d9bb
Names like "fetch" or "resolve" are heavily ambiguous and
continue to confuse me. I hope these new names reflect better
what's going on.
Bug: T288827
Depends-On: I587a203a9370e4742f87586b4f1867b37459c375
Change-Id: I8fa47ed313e7d7b2c114a5638a67c4f3c8b830f1
This merges all code-paths that re-select a part (i.e. an input
widget on the right side of the template dialog).
Note there is an edge-case that actually changes with this
patch. When a page is removed, and creating a new page fails,
there is an `if ( page )` check. Before, the behavior was that
nothing gets selected in this case. After this change the
behavior is the same as if a page was removed: the closest one
gets selected. Not only does this make more sense. The `if` is
only a fail-safe anyway and should not result in different
behavior.
Bug: T288827
Change-Id: Ibb0260587588fb51a876658b16a81c5a73371dc4
What this changes:
* The moment the user selects anything in the parameter search
widget, the input is cleared, no matter what happens next.
Even in case of an error. We know the input was bad in this
case. Let's get rid of it.
* The method makes sure it does not even try to add a
duplicate parameter. This should be unreachable, but better
be safe than sorry.
This is split from I5eeb973. I run into this while playing
around with different approaches related to hiding deprecated
parameters. Typically there should be no way the parameter
search widget offers a duplicate. Still I believe it's a good
idea to have this extra safety-net.
Bug: T272487
Bug: T288827
Change-Id: I04e76d73b4a3f6467d0ccf3ccff5d2f6b4114bd9
* getPartId() is unused.
* Use this.data instead of a custom this.partId.
* No need to store this.header as a property.
* Rename the event to "headerClick". That's enough when the
event comes from a widget that does have the word "part" in
it's name.
Bug: T274544
Bug: T288827
Change-Id: I8c70425403c6cd6a19e3a1cacb2b085e5c8b2e46
The base widgets we are going to use (notably OO.ui.OptionWidget
and OO.ui.SelectWidget) also have events, and some of them use
the same names. Such conflicts are really hard to track down.
This is meant to be temporary. The goal is to use the events
from the base classes and get rid of the custom ones, if
possible.
Bug: T285323
Change-Id: I0f103a5bbb8fb800e57009e3bf709f00a651fdda
The problem here is that the OO.ui.OptionWidget base class
(changed in the previous patch) also contains a .setSelected()
method, but with slightly different behavior. This results
in crazy behavior when I try to make the outer widget an
OO.ui.SelectWidget.
Renaming the method to be a custom, private helper method
avoids this problem.
The plan is to actually use the default setSelected()
behavior and get rid of the helper method. This will be done
in later patches.
Bug: T285323
Change-Id: I84e752f20a4d07007fd4e61989f9b34983410950
As preparation to introduce then new UI to add unknown parameters.
This is a few things:
- Merge the code paths when adding a MWTemplateModel
- Put code adding parameters to the dialog next to each other so
that preventing reselection happens around that block
- Reduce duplicated code when re-focusing after addition
- Move adding the placeholder page to the end
- Add and clean up inline documentation
Bug: T272487
Change-Id: Ic700edd42027a928a236ed11f2c257fffe994257
This removes the paramter placeholder page from all places where it's
not usefull anymore under the new sidebar.
The new UI will be re-added in follow up patches.
Bug: T272487
Change-Id: Ifc6f6f64fed1a1b23c92282e2a1bb40a7d401d72
The plan is to change the outer …TemplateWidget (which contains
a list of template parameter checkboxes) into a SelectWidget.
But this requires the elements in the list to be a subclass of
OptionWidget.
Note this change does not have any effect, as of this patch. But
this makes the following patches smaller and easier to follow.
Additionally:
* The OptionWidget class is already a LabelElement. No need to
initialize this twice. This happens via the parent constructor
now.
* Remove CSS that is not needed any more after Idc5e048. This is
not a FieldLayout any more.
* Update some related code documentation.
Bug: T285323
Change-Id: I92e8fd2bbece9e6c55083cdfe6ed7ad16a64d688
The icons have a padding of 6px around the icon image itself. To
get to the required 16px/8px space the margin was adjusted
accordingly. Note that there's also a 2px padding around the menu.
Bug: T272482
Change-Id: I3df9f355dfd5c4e6366432555b96bf788e784280
This is what actually happens:
* We call `addParameter()`.
* This triggers an `add` event.
* This calls an `MWTemplateDialog.onAddParameter` event handler.
* This code doesn't check if a parameter already exists (because
it shouldn't). It detroys the page in the content pane on the
right and recreates it from scratch.
The only reason we do this is to focus the input field on the
right. This patch introduces a dedicated event to do this.
Bug: T288827
Change-Id: I47effe05427cfabfcf534920edee79521eaa033f
I found this while working on T274551, which is all about the
definition of "empty".
In the old sidebar a parameter's name is dimmed (gray) as long as
the parameter's value is empty. This stops working entirely when
there is a default value.
My first impulse was "this is a bug". When there is a default
value, both the empty string and the default value (when the user
enters it exactly) typically trigger the same behavior: The
template uses the default value, just as if the user entered it.
But this code is correct because of the way it is used. Only
parameters that are "truly" empty should be visually marked as
such. The moment there is a default value it is either impossible
to change this back to an empty string – meaning the parameter
can never be truly empty – or the empty string is meaningful user
input.
Bug: T274551
Change-Id: I90657bfe83e56afd3942428c0dd8a47b444e39c9
This should not have any effect on how the thing looks and
behaves.
* All elements in the sidebar should be reachable with the tab
key, including disabled elements.
* Enter jumps to the corresponding paremeter in the content
area on the right. But enter doesn't change the checkbox
state.
* Space canges the checkbox.
The class will be renamed in the next patch.
Bug: T285323
Change-Id: Idc5e04828ece0ba77a65e4c839cd3ffccc3b6733
As discussed in Ia44da16. This change avoids possibly hundreds
of events (when a template does have hundreds of parameters),
and replaces them with a single one.
Bug: T288202
Change-Id: Ic819e8c93e872b653c238f396f1f327b6a8759d2
There is still a lot to do, but this implements some basic
behavior that was missing before.
* You can now use the tab key to navigate all checkboxes,
including disabled ones (required parameters).
* Enter key now works on both the checkbox as well as when
the entire line is highlighted. Enter forces the checkbox
to be checked and moves the focus to the content area.
* Mouse clicks now work on the entire line. Before, only the
text label was clickable.
Open issues (not to be resolved in this patch):
* Clicking the text label and the empty space after the text
label does different things. Probably shouldn't.
* Should a click on the label check the checkbox?
* Space key should probably not move the focus to the content
area.
* Focus rectangle is different on disabled rows. Is this ok?
* Background color when a line is focussed is missing.
Change-Id: I22ccd1bea92e4f098d4b25a9e38cddde5c103423
The checkbox is the first parameter in the parent constructor.
The parent is the FieldLayout class. The checkbox becomes the
this.fieldWidget in the parent class. Just use this instead of
storing a duplicate reference.
Bug: T274543
Change-Id: I4ae7d467334f88f2be93a62660145a025089401f
I get a scrollbar at the bottom of the sidebar. The reason is
that the container's width is 100% + 1px. The extra pixel is
from the border, which is not needed in this mode.
Bug: T274554
Change-Id: I4f749be6b9a7f89f9a7a195dc66c5c18253b1327
This is really only about the methods name, but doesn't change
any behavior.
I realized we work with several different definitions of what
"empty" means. There are at least two significant definitions:
1. When a parameter's value is the empty string or identical
to the default value, the behavior of the template is the same.
It will use the default value just as if the user entered it.
The auto-value is a meaningful value in this scenario and can't
be considered equal to the empty string.
2. The context here is when the user presses the back button.
This will destroy all user input. But an auto-value is not user
input. It will appear again when the user realizes they made a
mistake. Nothing is lost.
Personally, I would not use the word "empty" to describe this
concept. Things like "containsUserProvidedValue",
"isCustomValue", "isMeaningfulValue", … come to mind. These are
all still a big vague. A "user provided" value can be identical
to the default or auto-value. "Custom" how? I went for
"containsValuableData" for now.
Bug: T274551
Change-Id: I2912a35556795c867a6b2396cbad291e947f0ed6
This is a direct follow-up to I6ebd020.
Steps to reproduce the bug:
* Make sure you have a template with a deprecated parameter.
The position doesn't matter.
* Add the template. The deprecated parameter is hidden.
* Add an undocumented parameter, e.g. "b". This is added to the
end, as it should.
* Add an undocumented parameter "a". This should appear before
"b", but doesn't. The reason is because the invisible
deprecated parameter is in the list that is used to calculate
the index, shifting it by 1 (or more when there are more
hidden parameters).
This patch includes a few closely related changes:
* We can loop the list of checkboxes directly instead of
indirectly via the list of parameter names.
* I made it so that an active filter only resets if it would
hide the new parameter. The original problem we had to solve
was that the new parameter would always be visible, even if
it doesn't match the filter. This awkward mismatch is still
guaranteed to not happen.
Bug: T274551
Change-Id: I1b0480ae836cc19b77b159d3fb30ff32e8c59df4
I came up with a new event to do this. This event is triggered
individually for each parameter. An alternative is a single
event that gets a list of visible parameters. Is this better?
What do you think?
Bug: T288202
Change-Id: Ia44da16917c28171a01aef0f1c613dcd5d3266ba
This is – for now – intentionally done in a way that can be
undone. This will still be helpful for debugging for a while.
But we need to get rid of the duplication to be able to make
this new functionality visible on the beta cluster.
Actual removal will hapen the moment we actually remove the
old toolbar. There are already tickets for this.
Bug: T286765
Change-Id: I842c3c39a55a273af20643fa8a602d2e57fb6b8c
This affects only the new sidebar. Deprecated parameters don't
get a checkbox, except they are used already. "Used" includes
parameters that are present, but empty.
Bug: T274551
Change-Id: I6ebd020d02650c19060345d13495373acab363df
Disambiguation pages are rarely the page users intend to link to,
especially with newbies. By moving the disambig page(s) as the last
result, the user is more likely to pick the page they actually intended
to link to.
Bug: T285510
Depends-On: I2b8545f6dd4849629037f81f48a540748e60da83
Change-Id: Id55a19e7665d8f88559c471de36e5447fb2babb0
With this users can also filter undocumented parameters
that they added to an empty starting template.
Bug: T272481
Change-Id: I99adb38b0ae4d4ade91fcb506f10c0222b9bb5e8
Note that this patch alone probably does not make that much
sense. The code executed is pretty much the same. The only
difference is that the empty (!) …ContainerWidget is kept
and re-filled with what might be a completely different
template.
This is not much of a difference to before when the
container was recreated.
This change will make more sense when the container has to
manage more state, e.g. focus states. This state will
survive then.
Change-Id: Ic336d10a595e3e222741a3dc57c1d54639166b7a
This ellipsis was there before we started working on this code,
but was never working properly.
We understand that the CSS was intentionally done like this (as
the comment explains). However:
* We changed the width of the dialog. The old value doesn't
match any more.
* The width is different when the sidebar is expanded vs. when
it is collapsed. Even if we update the number, it won't
always work.
* The 100% work fine in current browsers. I can only assume
this was different back in 2014 when this CSS was written
(see Ia8259e9).
Bug: T285044
Change-Id: I3de2b0ed0b6a05d2b9fa0b325a2b12277564b271
Notably:
* Don't require the model in the new sidebar via dependency
injection, but connect the event handlers later. This is
relevant because we currently create the new sidebar in the
wrong spot. Removing the hard dependency allows us to split
the code and utilize initialize() and getSetupProcess()
correctly. This will be done in a following patch.
* The change event now includes the new position. This makes
it very easy to add this missing feature to the new sidebar.
Also:
* Stop triggering change events when nothing changed. These
events are expensive. They bubble all the way up to the
TransclusionModel, and to all linked
onTransclusionModelChange() handlers.
* Update event documentation to make this more visible.
Bug: T274544
Change-Id: Iafe29f18a6fed14d9c3124c9756aa840886afbbc
Notably:
* Include parameter aliases, labels and descriptions in the
search.
* Don't use a possibly outdated search index, but live data.
* Clear filter when a new checkbox is added.
Bug: T272481
Change-Id: Ie90a803af6178a8bb6de370a0f8e079800d9f8a2
In detail:
* Allow clicks on all elements in the new sidebar. This should
focus the corresponding element on the right.
* Make all elements in the new sidebar tabbable.
* Fix MWTransclusionOutlineTemplateWidget.createCheckbox() to
not need a temporary param object any more.
* Rewrite more code in MWTransclusionOutlineTemplateWidget to
be shorter and easier to read.
* Fix MWTemplateModel.addParameter() to not do way to much
stuff when a parameter already exists.
* Update code documentation.
* Use more specific, less ambiguous variable and method names.
Bug: T274544
Change-Id: Iaf6f7d1b0f7bf0e9b03eb86d01f3eceadece6fe4
Clicks on the left side now focus elements on the right
side.
This patch also simplifies the …ContainerWidget constructor.
The config parameter should only be used for "OOUI things"
that are needed by subclasses and mixins. But the parameters
we have here are not "UI things".
Passing them as config passes them to classes where we don't
know what they do with it. What probably happens is that
some class keeps a reference to the entire config object,
which doesn't have a benefit and possibly blocks garbage
collection.
Bug: T274544
Change-Id: I0c0e4a1ba59dcb43141338ffe939c9c6783e000d
Actually reusing this OOUI mixin gives us a lot of well
developed functionality we need anyway. Most notably proper
event management, e.g. click events.
The number of CSS properties we need to override is managable,
I would argue. Let's see:
* Our buttons are not inline-elements, but should use the full
width.
* No focus-border left and right for the same reason.
* We want much more inner padding.
* We want a stronger hover effect.
* We need to fine-tune the position of the icon. This is
because of the inner padding.
* Need to get rid of a negative margin that's only relevant
for inline-buttons.
I currently feel like the benefits are worth living with
slightly more brittle code. Note that we can undo this change
any time because all this is well encapsulated in this new
class.
Bug: T274544
Change-Id: I33f275a958964d49e803e56bf74a6fa961093da1
This introduces another generic "button-like" class that can
be reused in multiple places in the new sidebar. The main
change in this patch is the "add more information" button
which is now an instance of this new class as well.
This patch also simplifies over-complicated setup code in
related widgets.
Bug: T274544
Change-Id: I0cfe7675d02fdd5c5dc8d9198bb3f4aec9abf397
Before, the new sidebar was hacked in a place where it confused
the BookletLayout logic. This became visible when using the
up/down buttons to move elements in the sidebar.
This new container wraps the new and the old sidebar. It also
uses a temporary color to make it easier to see where one ends
and the other starts.
Bug: T274544
Change-Id: I4e5b40b1d1556886fc85cff9e926a02e4888f032
The two new widgets are pretty trivial now, thanks to the base
class.
Note there is still no code to delete the widgets. That's also
why you will always see a placeholder widget at the top. This
will be fixed with the next patches.
This patch also renames most of the "…TemplateOutline…" classes
to "…TransclusionOutline…" The reason is that these widgets are
not for a single template, but part of the container widget for
a more complex transclusion (i.e. a sequence of multiple
templates and wikitext snippets).
Bug: T274544
Change-Id: If4219b0b8ad4d1969ab1ec5ec4db0728811bab35
The icon and the name of the template are now created by the
base class. This is meant to be reused for other elements
that are not templates.
Bug: T274544
Change-Id: I76bbc0e8c0420e9c6357d093d5f5e1651a0c2719
Reasoning:
* format=json must be the default. Nothing else makes sense in
the context of this code. This should not be a surprise.
* formatversion=2 is only a default when the custom
getContentApi() is used, but not when mw.Api is used. One
might argue that it's safer to always specify formatversion=2.
However, this is not done in other places in this codebase.
It should never be done or always.
* I find it confusing when the action=… is missing. Let's not
rely on this default.
Change-Id: I6ca29f76bffc0849103c5bcff4aaf28fcaaa4c52
This code doesn't do anything but adding an empty <div> to
something that is already a <div>. It doesn't even have a
class name, i.e. it's not referenced from anywhere. We can
add such containers back any time when it turns out we
actually need them.
Bug: T274544
Change-Id: I62546cc7939364db31f37b9de0c035974554544b
This base class will be used to style the 3 types of top-level
items in the sidebar the same way, without the need to
duplicate code or styles.
Bug: T274544
Change-Id: I1a62ff610728d7150dea1717316ef20f6882783a
This matches the existing naming scheme better. I also plan to
re-use this class for other types that are not templates.
That's why the name is the more generic "transclusion" now.
This patch also removes a `padding: 2px` that's not that
helpful. We will need paddings later, but need to choose them
much more carfully.
Bug: T274544
Change-Id: I6f0f630da2230b023b3fb065e5ad86d8211bb7b3
Because the API uses a generator, the search results are ordered
alphabetically. The actual search result ranking is in a .index
field. This code accidentially deleted the alphabetically lowest
template instead of the least relevant one.
Change-Id: I79de024feb569e9f06bedab908a6509a4d4fa99b
We do this additional prefixsearch anyway. What we did before
was ignoring the result when it was not a 100% exact match.
Instead we can always add this 1 prefixsearch result when it
was not already part of the CirrusSearch result set.
This won't happen often. Usually the 1st prefixsearch result
was already part of the CirrusSearch result set anyway. But
if it wasn't, that's a serious issue for expert users that
expect the search to behave similar to the suggester at the
top of the MediaWiki interface (which is also a prefixsearch).
Change-Id: I959d2b058a3d64596a8cfbe5476ab351e40f8760
Some details:
* The config is not optional in these cases.
* This patch continues to remove some comments that don't add
any information but just repeat what the code already says.
Change-Id: I5c27cd01ad80709bb583256821d65c6b65b74b05
For example, checking if a parameter is required works just fine
for unknown parameters. They are never required. Since I16708b0
we don't need to guard the spec related methods any more.
Change-Id: Id90e4cb810dc9faca3b26f122a534f276ee31709
It's good practice to make transparent elements transparent
for mouse clicks as well, i.e. make it possible to select text
behind the fade effect.
Bug: T283943
Bug: T286235
Change-Id: Ib5022a74c70e4b7cb5e2a0faad20bd9abcc0da36
Introduced in 2 separate patches by the same author. This
patch removes the line that was introduced last.
Change-Id: I77575f7afe0f9276c7b54ee44d828e7ccb87c978
These methods are special in so far that they create *minimal*
wikitext where optional whitespace is not preserved. I tried
to rename the methods to reflect this, but could not find a
caller. What's used instead are the .serialize() methods.
Bug: T284895
Change-Id: Iedaa5b7efa9675151cc0553854d8aef3f9a46cbb
If a known parameter is present using one of it's aliases, then
only the aliased name should be shown to the user. This patch,
therefore, resolves the issue of the same parameter being added
to the sidebar twice.
When adding a parameter that is aliased, it will receive the same
position as the non-aliased parameter it is replacing.
Bug: T274545
Change-Id: If4e58c941fd0f0e690d3603935f5a5d3f9938163
It's allowed in values, but not in parameter names. The moment
a parameter name contains an `=` the parameter name will be cut
off at this point, and what's behind the `=` will become part
of the value.
You can test this on any live wiki. Open VisualEditor. Edit any
template. Add a parameter with a name like `a=` and some value.
Switch to wikitext mode and back. Edit the template. The `=` is
now part of the value.
Bug: T98065
Change-Id: I5e00e8fac987471243605816b041d3638927ac3b
When what you type is a partial match, you can't add it as an
unknown parameter, even if that would be the correct action. The
reason for this unexpected edge-case is a mistake in the code
where a variable called "exactMatch" is set when a *partial*
"nameMatch" was found.
Bug: T285940
Change-Id: I6d12e2d7251a19d7d5f8be544c3c32a3ac14fcf0
The so called "spec" class keeps track of parameters that have
been used before, no matter if documented via TemplateData or
not. Removed parameters are still "known" (i.e. have been seen
before).
This feature allows to easily find previously used parameters
names when an undocumented parameter was removed and the user
tries to add it again.
Bug: T285483
Change-Id: Ia1555eea87cd99e7a3f386f4279ec5a80fb98a79
I rearranged this piece of code like a dozen times before I
finally understood what it actually does. This should be much
more obvious now.
The idea is:
* If no edit was made the button is always disabled.
* You can save pretty much everything, except when the
transclusion still starts with a placeholder.
* You can also click the done button when the dialog is empty.
This feels a bit odd, but was like this before. I think this
codepath is unreachable. But it probably doesn't hurt to
keep it.
Bug: T284895
Change-Id: Ic483201b64fd64f414c5b1ec4c44198b8eadb9f2
These tags don't do much, if anything. But they provide a hint
in which scope a method might be used.
Bug: T284895
Change-Id: I0b4bdd416ee89d26961c4ded4d8bbace8c57da76
While the term "canonical" is not wrong, I find it still
somewhat ambiguous.
1. "Canonical" could mean different things. E.g. is the order
of parameters as they appear in the article's wikitext the
"canonical" one? It's possible to argue like this, esp. if a
template doesn't have TemplateData documentation. In this case
the only order known is the one from the wikitext.
2. "Canonical" sounds like the parameters must be reordered.
But this should never happen. Not having dirty diffs is more
important than having the parameters in a specific order.
Bug: T285483
Change-Id: I23658d37fea50b727667677ac6a49066673b2135
This reverts commit 950a5300dc.
Reason for revert: This broke several workflows. The reason is
that MWParameterPlaceholderPage & MWParameterSearchWidget both
hold references to the MWTemplateModel. This model is not
always the same. The dialog might be the same when a template
is edited multiple times. But the model might be a new one.
From this point on the MWParameterSearchWidget pulls data from
an outdated model.
Bug: T284636
Bug: T285571
Change-Id: I7b9ea8cab8f17705ec8020f07e3732da6ba0e73c
This does not revert commit 950a5300 but applies the most
minimal hotfix I could come up with.
The reason for the breakage is that MWParameterPlaceholderPage
& MWParameterSearchWidget both hold references to the
MWTemplateModel. This model is not always the same. The dialog
might be the same when a template is edited multiple times.
But the model might be a new one. From this point on the
MWParameterSearchWidget pulls data from an outdated model.
This extra check compares this model reference and creates a
new widget when it changed.
Bug: T284636
Bug: T285571
Change-Id: Ib3eca52bbff90ffbf56a257e3984adcbe02b310b
There is a codepath where `modelPromise` is undefined and
calling `modelPromise.then()` fails. This codepath implies
that the dialog is empty and there is nothing to update. We
can just close the dialog then.
I found this while debugging the actions in this dialog.
This happens when the dialog is empty (except for a
placeholder) but you submit it anyway. This is typically
not possible as the button is supposed to be disabled.
Still I think it's a good idea to make this code less
fragile.
The relevant code was introduced in Ibc2fc66 (2016).
Change-Id: Ia6b723548456c211b944a2320949bfc23b0afa16
This reflects much better how this method is meant to behave.
Note I will continue to remove documentation that doesn't
explain anything in addition to what the code already says.
Bug: T285483
Change-Id: I81fa8a5d9d0752f3aeac4015c9a27b50e054d4df
This makes the code more readable and easier to reason about.
The ESLint rule responsible for this code style was removed
just recently.
Notes:
* I focus on classes that are relevant for what the WMDE team
does right now.
* I merge multiple `var` keywords only when the variables are
strongly connected.
* Caching the length in a for loop makes the code hard to
read, but not really faster when it's a trivial property
access anyway.
Bug: T284895
Change-Id: I621fed61d894a83dc95f58129bbe679d82b0f5f5
This reverts parts of I678bb24.
Brief history of this code:
2014: The dialog was designed to dynamically change the title.
There was never a tooltip.
2016: A change in OOjs changed the behavior in VE. Now the initial
title shows up as a tooltip. It never updates because VE
does not know about this. The tooltip does not match the
visible title.
2021: We revert to the behavior from 2014. We achieve this by
bypassing the codepath that creates the tooltip. This is why
….title.setLabel() is used instead of ….static.title.
Bug: T276568
Change-Id: I346a904881c3a63186d6a80afdaf717688bab42a
The tooltip is useful for languages where the dialog title might get
truncated. This patch makes sure the tooltip is always the same as
the visible label.
Bug: T276568
Change-Id: I678bb243bb5ac6d1c516ee4e146f2db9ffd5afcf
This will avoid that the search breaks in edge cases where symbols
are used.
Including a fallback for ES5 browsers. The fallback should cover
almost all cases. Worst case would be not adding the asterisk even
though it might be valid.
Bug: T284554
Change-Id: Ie4aee0b77492b7a73bc251a8723a206dbd641600
We have to move the activation logic from a ve.ui.Command to the
ve.ui.Tool, as the Command is unable to refer to the Target.
Previous attempt: 4984c5ffbb
reverted in fb32aa4978.
Bug: T279313
Change-Id: I3cb74aa5123b67a6c63b8e07ea7f93a6d4a07d4f
This not really just a checkbox widget anymore it inherits from
FieldLayout and became something more in that direction.
Let's use a mixture of these things to make it a bit clearer.
See also comment in Ie81b84be288553343017c4aaf8691c4e266995f5
Change-Id: Iff1746a8e5e94b56eb6c27465405aaf6b74c2310
Most notably:
* Introduce variable names that explain much better what's
going on.
* Reduce nesting.
Bug: T284895
Change-Id: I793677d8107abb6354f9e19d79c4879a41c4bd93
This action was removed via Ib744b89 in 2019, see
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/491537/4/modules/ve-mw/ui/dialogs/ve.ui.MWTemplateDialog.js
Note the messages that are removed in this patch:
* …-action-insert was used for the "insert" action.
* …-action-apply was used for an "apply" action.
* …-action-cancel doesn't mention an action. Internally,
the cancel action is "".
Since Ibd740ad the actions are registered in the
FragmentDialog superclass, see
https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/491536/2/src/ui/dialogs/ve.ui.FragmentDialog.js
Note the messages. Cancel is unchanged. …-action-insert and
…-action-apply are still there, but both linked to the same
"done" action. The "apply" and "insert" actions are gone.
I.e. they are merged into a single "done" action, represented
by a single button that changes the label from "Insert" to
"Apply changes" when needed.
On top of that,
MWTransclusionDialog.updateActionSet() replaces "Apply
changes" with "Save".
Note: Other dialogs also mention an "insert" action. I didn't
look at these. These are not in the focus of our team's
current project.
Bug: T284895
Change-Id: I1d35ada3b5b2049ed20c2d940a1c065b704c978d
The "mode" button is the button that allows to expand and
collapse the dialog. It can't be collapsed when multiple
templates are edited. That's what these lines do,
disabling the button.
"Can expand" is not the correct question. It's always
possible to expand the dialog no matter what it contains.
Bug: T284895
Change-Id: I60f3060695c80bf5541ef2156be89b85a62bf91b
Introduces new widgets forming the backbone of the experimental
template dialog sidebar.
FIXME: `text-overflow: ellipsis` is not working yet, the container
styles need adjustment.
Bug: T274543
Change-Id: Ie81b84be288553343017c4aaf8691c4e266995f5
Both the template description as well as the parameter
description (including default value and examples) typically
contain longer texts. These can contain longer words that
"explode" the design. This is trivial to avoid.
Note this is not meant to fix this issue in all places where
it can appear. For example, a long parameter name causes the
same issue. But:
* Technically, it's not that easy to fix.
* Even if, it's not obvious how to fix it. Cut off the
container? Add ellipsis? Or wrap? How should the
surounding stuff float then?
This is all left out because of this. Focus on what's
obvious.
Bug: T284890
Change-Id: Id6700af168f5ab5ddde97d3f5ae63829b65a3be5
* Re-focus the input field after closing the message.
* Store only the message key. That's all that's needed.
* Avoid a class property that's not needed.
* Use the config object instead of calling .setLabel() manually.
Bug: T284742
Change-Id: If8e8bb6460fa5aea8ddd46c2e27b5f08b7772896
We can skip all the up and down message passing by persisting the
parameter placeholders for each template dialog. If the parameter
list is expanded then the placeholder is deleted, on being created
again it will still have state.
To test: create a transclusion with two templates, each having many
parameters. "Add more information" to add parameters, expand the
list by clicking "Show <num> more fields", then delete the parameter
placeholder using the trash cans. Try different permutations to fool
the cache or collide with another template.
This is preparation for other template sidebar dialog work.
Bug: T284636
Change-Id: I23bdd38b173114c2a9afafc7465c4beb92d25869
These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
Begin to extract the wiring between a sidebar and the content pane of
the template dialog booklet layout. Eventually, this helper class
will present a high-level interface like "addPart(id)" and will take
care of creating the outline item, content page, and connecting
events.
Start very simple, take over the "focus" method.
Bug: T284632
Change-Id: I7bc73cc4386b99d95941fc6ed88ab5bd998de014
This reflects better what the method actually does. This patch
is a direct follow-up for the renames started in Ib029fd4.
Change-Id: Ie3e87139a5c2f5ac196e0fcc02fb897fadc99177
The names of the messages keys are very confusing. The order was set
wrong during refactoring in Ib029fd48b393d2ab7d7cff6c842789e22989e944.
We should rename the keys in a follow up in sync with translatewiki.
Bug: T284649
Change-Id: I43794d80b7df7d00441cb583ca53bcab03999e65
This dramatically simplifies the "mode" flag in
MWTransclusionDialog. The main reason to touch this code is:
The flag appears like it will be "single" when the dialog
contains a single template, and "multiple" when there are
multiple templates. But this is not true.
What the flag really does is show/hide the sidebar. The sidebar
is needed to be able to create multi-part templates. But a
dialog that already contains multiple templates can be set to
"single" mode (i.e. the user can collapse the sidebar), and
vice versa.
This patch focuses on private details inside of this class, but
keeps the terminology of a "mode" in some places. E.g. the
messages are not renamed to not cause unnecessary trouble for
translators.
Change-Id: Ib029fd48b393d2ab7d7cff6c842789e22989e944
Previously, if the checkboxes were shown on multiple lines (e.g. due
to a FlaggedRevs checkbox), there would be uneven margin at the
bottom. There was a special case to fix this only for the watchlist
expiry not-checkbox.
Change-Id: I006049cf23e6d42519bfa15b7ec30ea1bc5d08ac
This class represents a raw wikitext snippet. There is also no
base class that would require us to follow a generic
getValue/setValue naming scheme.
Change-Id: I0891a2f6c0ae0121429a47c39221e99b9653e8e3
There are 2 methods with the same name, but they are very
different. This makes it much easier to understand the
difference, I hope.
Change-Id: Ie1f049b2b14e1fe23f078e281ee797da29dfe3db
This does have a few advantages:
* Less code is executed and less memory consumed when these
elements are not needed.
* Code that belongs together is together.
* No local class properties are created when they are not
needed in the code below.
This patch is kind of a proof of concept. It touches only a few
classes we currently actively work with. If this change is fine
we can change some of the other classes the same way.
Change-Id: I9f548765034f1f69799fff41aeb6c147ff28b82d
The idea is to possibly rename some of these classes, based on
these descriptions. But this should be done in later, separate
patches.
Change-Id: I7f9e5b2382711b434d6dd618489fa3ed8b7a46b4
The main motivation for this patch is actually the comment. The
so called "spec" contains all parameters that are present in a
template, no matter if they are present in the TemplateData
documentation or not. This is critical here.
Change-Id: I5e1c79e3859a27562a9dea1d450cec196aa572ed
Depends on whether this is a new or existing template transclusion.
Split from Ib9b76cac7cd57245e8db2ef10879069a86a6269e
Bug: T276568
Change-Id: I4d22e32fef067b640e9a9389deffaace736c3405
When the existing search results don't contain an exact match
(see previous patch), perform an additional search for the
title. This uses OpenSearch. This is recommended in multiple
places and also used in the quick search field at the top of
MediaWiki.
Again, I came to the conclusion that an isolated unit test
would be complicated and not test much anyway. Better test
on-wiki.
Bug: T274903
Change-Id: Ib575248e089ff66814400202d224deff6369c772
This code detects a few edge-cases:
1. When some search results are exact matches, make sure they
are always at the very top.
2. When the prefixsearch API is used, e.g. as a fallback,
redirects show up as a separate metadata structure outside of
the pages array. Consider these and stop if there is already
an exact match.
3. CirrusSearch returns redirects as part of the pages array.
When there is an exact match, make these redirects separate
options and add them to the top.
All of this is case-insensitive, on purpose. In case two
templates with different capitalization exist, we rely on
the backend to return both. The code introduced here is fine
with this.
Notes:
* This doesn't guarantee an exact match is always there. This
requires an additional HTTP request and is done in the next
patch.
* I tried to write unit tests for this, but gave up. The setup
is complicated. An isolated unit test would not test much
anyway. Better test this on-wiki.
Bug: T274903
Change-Id: I64e1b5633e7b878a4d0d23d66229ca87e69d0045
These are the most minimal (and therefor most stable,
hopefully) hacks I could come up with so far.
Bug: T274903
Change-Id: I28ba414dd34aad756e29400eb656f0942291a923
