Turns out we have two concepts, now represented by two methods:
1. A top-level part can only be moved or removed when it is actually
selected. This is relevant for the toolbar buttons and for the
keyboard shortcuts/hotkeys. We intentionally block the buttons
and hotkeys when a parameter is selected.
2. Adding a new part or parameter is always possible, no matter if a
top-level part or parameter is selected. This is again relevant
for the toolbar buttons and hotkeys.
Bug: T313388
Change-Id: I17caf8fce9d8f1ebe21660cf8c6d91ace8423490
Same issue as in the previous patch, but less intrusive. It was always
possible to add a new part, but it was often inserted at the wrong
position. It worked only as intended when a top-level part was
selected. When a parameter was selected, the new part was always
appended to the very end of the transclusion, not after the selected
template.
This is now a little bit of duplicate code. We might extract this to
a method in a later patch.
Bug: T313388
Change-Id: I1327222969d1d315bdacf3998f366d88c4c26bd5
The hotkey was only working when a top-level part was selected, not
when a parameter in a template was selected.
Some outdated helper methods are now marked as deprecated. They will
be replaced and removed in later patches.
Bug: T313388
Change-Id: I5ffe45fd00c36b97ee36dc0ba6831db5a941c731
This is a partial revert of Iaf089f4. It restores the old behavior:
* In case there is already a highlight in the parameter list, just
keep that. Usually there is no highlight at this point, but better
have this check in place to be sure.
* Otherwise always start at the top.
Jumping to the selection is confusing, esp. for keyboard-only users.
The argument goes like this:
* Let's say I'm in the middle of editing values on the right side of
the dialog.
* I want to navigate to the sidebar. How do I do this with the
keyboard? I use the tab key.
* Pressing tab also implies I move the selection to the next
parameter. And the next. Until I reach the end of the parameter
list. Then the selection stays there.
* When I finally reach the sidebar and tab into the parameter list,
the last parameter is selected. But this was merely a side-effect
of me navigating the dialog.
Such a "selection becomes highlighting" behavior was not specified
in T311204.
This patch is requested and approved by PM.
Bug: T312647
Bug: T311204
Change-Id: Ie5b5dfd4fca132050815e6182845ca23adb5f805
Before, permission editnotices didn't have access to the page titles, so
magic words like {{PAGENAME}} would give a subpage of Special:Badtitle. This
formats the message in the appropriate context.
Bug: T313372
Change-Id: I93894a4fc129de9da4b120c084b1d343b4021cdd
This should make zero difference in most situations. Except you
navigate a list of parameters with the keyboard. In this case the
SelectWidget gets a dark blue outline which overlaps with the light
blue selection bar, but the outline disappears behind the bar. This
looks odd. Making the color transparent fixes this without the need
to fiddle with z-index or such.
Bug: T311204
Change-Id: I7049eb60dc0ea72c2c4620f4351525fe447e0f46
The main motivation is to get rid of the vague method name
"setParameter" that was previously used for three different methods
in three different classes. Now the three methods have three
different names.
Change-Id: I938de30b368daf6ce3385b2ed2bca98f316593e1
We would love to name this state "selected", but that term is already
used for a template parameter that is checked/used. The idea of "set"
was to have a list of parameters where one is "set". But the word is
confusing. I suggest "active page" because the entire purpose of the
blue selection is to highlight the currently active page (i.e. the
one you currently interact with on the right side of the dialog) in
the sidebar.
Change-Id: I5a16ab4c193ea05c21bb3bf89ada2ef550d8d6bc
I hope this makes it a little more readable. The two steps done in
the loop are mostly independent:
a) Find pages that should be removed.
b) Find next best top-level page when the current one is removed.
Change-Id: I600253fb206a31ef5851865e733b66c336d5014d
This does not have much of an effect, but can cause visual glitches
in rare situations. One goes like this: Use the keyboard and tab key
to navigate to a list of parameters in the template dialog. Press
space to enable the checkbox. The parameter gets a blue background
(= it's now the active a.k.a. "set" item). Press space again. Blue
disappears, as it should. Press space again. Blue is now missing.
Bug: T312213
Change-Id: I3071ec4d0a05e3505ec5216acc5a97b8eaf6f5d5
1. Before, removePages() was calling setPage() with null. This makes
sense for removed top-level parts because these are really removed
from both sides of the dialog. Template parameters are never removed.
Only unchecked (and removed from the right side of the dialog, but
this is not what this code is about). When I navigate a parameter
list and uncheck a parameter I need the focus and highlighting to
stay.
2. We have a dedicated method when a parameter is unchecked. This
can check if the removed parameter is also the selected one (called
"set" in this code) and can reset this state. Without losing the
highlighting or anything else.
Bug: T312213
Change-Id: Ibb717ca49cae805617ebee196937c79daa72f1c1
There are many errors that are temporary in some way, and treating
them as unrecoverable is a poor experience.
Even for errors that really are unrecoverable, our interface works
poorly, because you need to hide the error message first to do
anything else, and you need to close the dialog to see it again.
This distinction is not really helpful, let's get rid of it.
Bug: T307330
Change-Id: I9680cc416da5b27881aeb3502f506dcb5d4bb71f
Optimization: Don't search for a checkbox that represents a not yet
named parameter placeholder. There is never one.
Fix: Store null, not undefined.
Bug: T312213
Change-Id: I395008f15d13133ad456d0a77571b7aa1c7a7fc9
Steps to reproduce:
* Set a breakpoint or debug.log() at the start of
TransclusionOutlineWidget.setSelectionByPageName()
* Edit a multi-part template.
* Use the keyboard to navigate to a template name in the sidebar.
* Press space.
This is currently triggered twice. Let's get rid of the more obscure
one. It was introduced as part of Ic4ee673. I don't really know why.
Bug: T313207
Change-Id: I3ddc072f5d42c17249abc82026e0bf1a4be1dc6e
This also means we have to move the declaration/documentation of the
event up one level into the generic "part" widget.
Change-Id: I1b803201f8955b58136ee7f37c04c01edcd47395
The code that receives this event does not need to know that the
source is a "parameter". It's just some "item" in the sidebar. The
idea is to reuse the event for both top-level parts as well as
parameters. This will be done in the next patch.
Change-Id: I858040f5adf8e156b6013caaa527b3237b7bac0f
What I found is a single `$container.animate( animations )` that's
responsible for the misbehavior described in T312768.
This method is called from a few places. I think none of these places
benefits from making this an animation. This is often more distracting
than helpful, especially when navigating with the keyboard.
Bug: T312768
Change-Id: I90a80d6ae8c1b47ee22297d2520255cad890b90e
