The optimization removed in this patch is done twice. The effect is
that the loop does not end when it finds a match but the match happens
to be the current page.
This doesn't change anything. It's really only about performance.
Change-Id: I5c2de101eb2f14f814f00cf7eacf46b70346f4c8
This is not only fired when a parameter is added. It's also fired
when pressing spacebar on a parameter that already exists.
Change-Id: I245aa9f5938eb38c3a3f224a4d642d57068cf23b
This is not only fired when a parameter is checked or unchecked.
It's also not only fired when another parameter in the parameter
SelectWidget is selected. It's always fired just because the
spacebar is pressed. This is so we can scroll that parameter into
view.
Change-Id: Id621405b7ca3116cd4a06f474e49776d0830dccc
This line was added as part of I0229b63. While what the comment says
is still true to some degree, the line stopped being helpful when
we introduced sticky headers. When scrolling the sidebar for a
multi-part template with many parameters the sticky header jumps up
and down by this 1 pixel.
TL;DR: This is one of these hacks where it's better to remove it and
look for a better solution when we notice the original issue again.
Bug: T312768
Change-Id: I2fedea4e1d4d6c95c74a63c522821a6ebc2ee2b2
250ms gaps are pretty common when typing at a normal speed, resulting
in a lot of (often expensive) API requests (e.g. T312319). For most
use cases this level of responsiveness in the preview is not necessary.
Change-Id: I6504567d4da02a66171ee35a9c4fd35c85136909
This patch contains a small cleanup that moves the scrollIntoView into onSidebarItemSelected.
Since all other places already have a focus call, scrollIntoView is not needed there.
Bug: T312850
Change-Id: I1a3cb3905faea2bd8a6bf8dc4cfd748813e1c875
This regression from Iaf089f4b271fd853b17c1aa7f5938510ea8f5431.
Not calling the parent here was is essential, because when clicking
the checkboxes this event will trigger the focus of the whole widget.
That's not what we want in this case though. Also it seems we don't
need any of the logic from the parent and can get rid of that
complexity.
Bug: T312855
Bug: T312856
Bug: T312924
Change-Id: Ib3a2eeeb6d519dfa1bb627049f6b3a4708017e86
Using Parsoid HTML in the 2017WTE has enabled us to iron
out lots of rendering bugs over the past few years.
In that time Parsoid has been moved into PHP, and at some point
we also become the default parser.
Also more extensions have started to use content transform hooks,
which are only supported by the action API.
As a result it now seems like a good time to migrate back to the
content API instead of building the preview from Parsoid HTML.
Bug: T154844
Change-Id: I90d775dd71d5f5a61d651b63d946ab60a27e2ca3
Fixes a bug that crashes the interface when unsetting the focus after
another input was focused, because `page` is undefined in this case.
We were already calling `setPage` to unset focus, so document it.
Bug: T312017
Change-Id: I2926beffe23e0ee822f5690d4791534a5413886a
This can only happen when deleting the last part of a transclusion,
then we want to set the previous page as selected. This should never
be a parameter though.
Bug: T312221
Change-Id: I06700dcf37f6d4f7dd073f8f2bc1b8b0a17a62c4
Just putting this eslint auto fix out there. No hard feelings, but
a warning that pops up everytime.
Change-Id: I157e0338e5f5a6f27dbbd9ae116da0f922468586
Triggers scroll in all situations where highlighting changes.
Including keyboard navigation.
Bug: T312542
Change-Id: I849f64c5cefe0cac3fde6e848b23b7b0cfc489ce
Introducing a set method to have a different state for a set
parameter and a highlighted one in the selection.
Allows us to remove a lot of workarounds for missusing the
highlight state and fixes several issues with these workarounds.
Main implications:
- Keyboard navigation and mouse hover now sets the grey highlight
- If a parameter is set (blue highlight) keyboard navigation returns
when focusing the SelectWidget
- If nothing is set keyboard navigation starts at the top after focus
- Unchecking a parameter using space will not influence the keyboard
focus in the list
- Highlighting a parameter with the mouse lets keyboard navigation
continue from there.
Bug: T312647
Bug: T311204
Bug: T312213
Depends-On: I385dca1d95033961d3844e888521750443e49c95
Change-Id: Iaf089f4b271fd853b17c1aa7f5938510ea8f5431
This prevents an invisible and unactionable focus target when the
parameter search field doesn't match anything.
Bug: T312547
Change-Id: Ib29913a547cd68649d29e28d921c4c1358bad7b8
The last checkbox in the entire sidebar should get the extra bottom
margin, but not the last checkbox in each template group.
Follow-up on I1edc5db98d16a4c0de8abd7f705776fb9eb65b97
Change-Id: I4ffade9c053191ce202340edadbd032c67bb39a4
Causes problems when we remove a parameter using the spacebar, for
example.
This partially reverts Id3843b2c7ad6.
Bug: T312524
Bug: T312205
Change-Id: I65d834bc0d2cc649803b536ecc65bdd1fa166a32
Using a certain amount of depth to make sure to override OOUI
specificity.
More can be done in follow ups.
Change-Id: I1edc5db98d16a4c0de8abd7f705776fb9eb65b97
Should be a noop. Also moving one rule further up to the set of
similar selectors.
Removing one rule that was disabled for some time now.
Optimizations follow.
Change-Id: I8da70a52c13afd8ac1c3ff43bae63a203c3bf86a
We don't want to restore selection. Instead, we'll remove all
parameter selections onFocus, in a later patch.
This reverts commit 787d44af66.
Bug: T312017
Change-Id: Ia1dc8061dfd1813a58befff5adc5c3882b54d8e2
Gets rid of some unused behaviors that we've already disconnected.
Brings the remaining styling into VE files.
Bug: T312524
Change-Id: Ie94472019ba41124831621c45713861297219594
Both parts are not relevant anymore:
- The first part is about focusing parameter placeholder pages.
These are added after load only when using the keyboard shortcut.
Focus will be done separately in that case.
- The second part is dead code since some time now. Also it is not
needed here. Scrolling to newly added parameters is done via the
setPage() method in the layout.
Bug: T289043
Change-Id: I928afef01b9e62a9da91db10340d9df78717e125
This should be safe because selection is only set from use cases
in which we do want the sidebar scrolled to the matching item.
Bug: T290975
Change-Id: Ib0c66bb048768d633d0f638c775eba24cd652db8
... except on mobile because the keyboard will expand.
Need to disable a spurious focus when the element isn't visible,
because this was making it impossible to focus later once it becomes
visible.
Bug: T290975
Change-Id: I0e6057d1cfbef24324a287e50e4988f935720c61
Instead of using a potentially weird fractional value like 3.2 lets
use the floor(ed) value, e.g. 3. Reasoning: These fractions are not
from text lines but optional margins between some of the lines. These
margins should not be counted.
Also increase the cut point from >=3 to >3. This is much closer to
the original specification that talked about "2 lines plus x
characters". See T273426. These "x characters" are the 3rd line.
Bug: T310775
Change-Id: Ib5d1642d7967593dd5f13e556c6244fc44677af4
When blurring out of keyboard parameter navigation, the
last-selected parameter will be highlighted again.
Bug: T312017
Change-Id: I8b0fb667b44b324529d4c45c39bf21573517f989
`OO.ui.PageLayout.prototype.setActive` explains that the "active"
state only makes sense for a case we don't support, when a booklet
layout is used in non-continuous mode.
Change-Id: Ib5ddd605f29e82ebc85b833ac96b70ff4c95e502
Most of setPage's side-effects are redundant and can be skipped when
reselecting an item which already the current selection—except for
scrolling, which is useful to perform every time, for example when
clicking on the already-selected sidebar item.
Bug: T294348
Change-Id: I90ba14817e5536ac018eb70102f657f29a29644d
This was using the currentPage from the StackLayout. It will not
be updated there anymore.
Also removing the line about focus after toggle. We do not want
that anymore afaik.
Bug: T312015
Bug: T289043
Change-Id: I8b6eedd580d49604014118171c6da62849752d53
Tabbing into the parameter select list should highlight the first
parameter, but focusing a checkbox by clicking it to uncheck should
not trigger this highlighting.
Copied from the superclass method.
Bug: T312014
Change-Id: Ia1fd450bad4861eb2815ca21eae69ee31e40ac08
Only works with changes in OOUI core. See https://gerrit.wikimedia.org/r/c/oojs/ui/+/753987
Depends-On: Ie822dc87bc5748985de5637cb35f1940837f64d3
Bug: T299036
Change-Id: Idaccc7c95d67abe14621eabb7725ba07e449ab1e
New sidebar events take a `soft` parameter allowing reuse between
"hard" and "soft" selection and parameter add. The "hard" variant
causes a content-pane focus.
Bug: T311987
Change-Id: Ic49718840ae56eb4cfab01ce964a2fbc2d8db63b
More idempotent approach to state change, using a common function
that has all the side-effects.
Bug: T311987
Change-Id: I13e64ff5262295a60c28572855cfe36da7c3ff41
This becomes the canonical method to call when we want to update the
template dialog to select a new item.
Bug: T311987
Change-Id: Ie7880bfde41b77f0e6367cc8e3a78edb299391ce
Call the handler directly. This avoids the `set` event handling for
add and remove parameters, causing minor behavior changes:
Moves the "reselect" logic after removing pages, from StackLayout to
the two-pane layout class.
Bug: T311987
Change-Id: I46454d184d4718bed45caf9f41487364611f1f44
This event makes other calls redundant because it's always sent from
setPage and onReplacePart.
Bug: T311296
Change-Id: If214a713ed7299320d499c3e5687eda013fe0aab
In an important use case (spacebar selection of sidebar parts), the
content pane selection isn't updated. This patch switches to read
the sidebar selection rather than the content pane selection.
Bug: T311296
Change-Id: I684a9edf04b6615cc840bbb89e8c1d03a0ab8e94
If nothing has been selected, the action buttons should be
initialized in a disabled state.
Bug: T311608
Change-Id: I32fee0d73f6e13e09dc421c944df73b79e0260bb
No longer need to manage the connection between outline items and
content pane pages.
Bug: T310866
Change-Id: I8dae7efa18e97ce5e1c84d963f1a32f09dd7e7cb
It seems that the controls widget was the only side-effect we still
needed for maintaining existing behavior.
Bug: T310866
Change-Id: I507dacef4e56946b836b0fca31effce611260aec
This patch does a few closely related things:
* Replace a direct dialog → sidebar access with dialog → layout →
sidebar.
* Move the misplaced removeButton.toggle() to a more appropriate
place.
Bug: T311069
Change-Id: I5a2802aab587a6f7de4681bce4e9961a064ef8ee
We're not implementing a search widget with results anymore. It's
a leftover from the cleanup after feature flags got removed.
Bug: T310859
Change-Id: I9c177ae92a7d3e13a4fff248a6c86f1aab89f82c
The original intend of that rule was not clear to me and it seems
it got dragged along for some time. I checked the DOM in the
collapsed state to see where this could even apply in the new
interface and found no other place than the one where we overwrite
it again.
I guess it can go away.
Change-Id: I2886db33c5f06d1c49acc4743c9acc198339de36
These are internal to the two-pane layout and sidebar, so the dialog
doesn't need to be involved.
Bug: T310866
Change-Id: I5f05bc119dc213d8e31db62a3808a2fadaf35d99
This is a direct follow-up to I7f22e4b. I found that the way the
margins have been arranged became a little more complicated with
I7f22e4b. This patch tries to go back to the – I think – simpler way
it was done before.
It should look the same as before down to the pixel.
Bug: T311223
Change-Id: I2c7789922078fa98f15f0b65de4c0efdf878a13a
The one usage of this wasn't working. FIXME: maybe we want to
restore the behavior, to focus the first parameter in the dialog
after opening.
Bug: T310866
Change-Id: Ibe0151fbedb3a9716bb231b5d398c4ae670fd667
This defaults to false. It looks like this default is used in the
MWTemplateDialog base class. However, it also looks like this base
class is never used on it's own. All users we know use the subclass
MWTransclusionDialog where "editable" is true.
https://codesearch.wmcloud.org/search/?q=%2C%5Cs*ve%5C.ui%5C.MWT(emplate%7Cransclusion)Dialog&files=%5C.js%24
In the process I also remove some comments that literally repeat the
code and don't add any knowledge because of this.
Bug: T310867
Change-Id: Ie245aab80d1e77a8406f5591062e9cf49fd9613f
This code was meant to select the first parameter of a template the
moment it is added. It's at least partly broken because it doesn't
consider the so called "prompted" parameters that have been added
just a few lines above. It's a questionable feature anyway. We are
going to refine all focus-related behavior anyway. Let's remove this
broken stuff and reimplement it later (probably in a different place)
when we continue working on this.
The FIXME was added in I720ce1a.
Bug: T311223
Change-Id: I1801efe38387b5e7a1b76417c1e5d7db4e4b96d0
This was done in 3 rather "random" places:
1. Whenever a template is manually added. But rather late, after the
template was added, in an event handler that is about focus
behavior. It should not continue to manipulate the template that
was just added.
2. When the dialog opens with a template preloaded by name, as it is
done from the citation menu.
3. When the dialog is about to finish loading.
This patch fixes 2 issues:
* Get rid of a duplicate call (number 2 and 3) when using the
citation menu.
* Move number 1 to a place where it's executed much earlier, and
only when the user clicks "add template" in a template placeholder.
There is no other way to add a template to an existing transclusion,
but it's still a more appropriate place I feel.
Bug: T311069
Change-Id: I8a65ad703b95ba2092e9ef73493e9903e96b0dd6
This still works for a dialog with just the template placeholder,
because the page is already chosen as "current" in the stackLayout.
Bug: T310866
Change-Id: Ibc1d33b02d34f70548d9f7365e085847ef0b2a51
Includes moving CSS that already moved from the TemplateDialog CSS
file to the DialogLayout LESS file.
Width and height had no effect. Neither on desktop/mobile. I guess
the control's height covers for that. Float could be removed due to
the flex layout.
Some more specific rules could cover for the !important overrides.
Change-Id: I7f22e4be37c8f227845aed97281faefe26241091
