Sometimes, especially on a slow connection, search results may arrive
for a search query that is no longer in the search input, because the
user has changed the search query since the request was sent. When that
happens, don't display those outdated results.
Bug: T321108
Change-Id: Idd515a679673a7ddef02950323311a56cd2e84e9
The search input no longer expands to the left when focused, only when
there are search results. This meant the loader box was misaligned,
because it still expected the search input to expand.
To fix this misalignment, add the margin-left and width styles that
apply to the search input to the loader box as well.
Bug: T321009
Bug: T317902
Change-Id: Ic177b4cf56cb0a94850037a30db3001777dc52d2
Restricted to the feature flag (?vectorvisualenhancementnext=1)
for now to allow us to not worry about caching.
mw-ui-icon-flush-left and mw-ui-icon-flush-right have been in core
for some time and using them means we don't have to manage hardcoded
values for these.
We'll need to think of .mixin-vector-flush-left-left
and .mixin-vector-flush-right-margin-left separately - I wonder
if these could be revised to use these 2 standard classes.
Additional changes:
- Drop unused mixin-vector-flush-right-margin-left mixin
Bug: T321504
Bug: T317583
Change-Id: I51f8e31be6771a3fb32fb07dc22d0c2872b5706d
This removes the previously merged 835281 stopgap. Because of caching, this
should only be merged when the `emptyPortlet` class is not found on the user
menu container on anon officewiki.
Bug: I883926c36f59d446076f960ead31f82e51967e70
Change-Id: Ia1e9ba2b43186462b05f372368d5965fa0857657
Rename template and CSS files to match updated naming conventions, replaces instances of "sidebar" with "main menu"
Bug: T316570
Bug: T317437
Change-Id: Ib4050768f20b1734d356104f18aa539f657099d8
The legacy search wprov behavior, implemented in the WikimediaEvents
extension in searchSatisfaction.js, is to use acrw1_ as the prefix (i.e.
with an underscore before the index), and acrw1_-1 for user searches
that didn’t select a suggestion (not acrw1). Make the Vue search match
this in both cases.
Bug: T317682
Change-Id: I6c84533e1811233ff2727d501327471d73fc7b62
Making this a feature part of the feature management system is integral
to making this a toggle and will allow us to explore making this
persistent in future.
Bug: T319447
Bug: T319449
Change-Id: I80c7b892a6891094854b4154db90917b67986102
To avoid array query values to be used, see warning there:
"Array values are discarded for security reasons. Use {@see getArray} or
{@see getIntArray}."
This also fix that the falsy value "0" is checked against the regex
Bug: T321267
Change-Id: I29bc4a9a7fef5a6cadc0c6aa9fa1f4a03ccf9705
This ensures that the wprov parameter is included when users follow the
link as a link (click, middle-click, etc.), and also prepares us for a
future where pressing Enter after selecting a search result navigates to
that result’s URL instead of submitting the form. It also matches the
behavior of the legacy search form.
We put this in App.vue + instrumentation.js, not in urlGenerator.js,
because we also want wprov to be added when custom URL generators or
search clients are used. (The reason for instrumentation.js instead of
purely App.vue is just that it’s easier to test there.)
In the tests, we need to update @wikimedia/mw-node-qunit so that we have
a sufficiently functional mw.Uri() mock.
Bug: T317682
Change-Id: I765d3bbf89b2253add7b50305c362e4bbc9ecceb
* Removes server rendered vector-tab-noicon class from legacy Vector as it is
not currently used.
* Adds menuTabs.js responsible for adding the vector-tab-noicon class when menu
items are added to tabbed menus. This is only used in vector-22.
* Adds unit test
Bug: T320691
Change-Id: Iffad86125f8754305f592ddc19d894866bd6dedc
When `$wgGroupPermissions['*']['edit'] = false;` is set, an `emptyPortlet` class
is added to the user menu which prevents the menu from showing even though it
contains a login link.
Changes:
* Vector-22 now determines what classes are applied to the user menu's container
instead of core deciding that on Vector's behalf (L761 of
SkinVector::getUserMenuPortletData). This eliminates the undesirable
`emptyPortlet` class. This can potentially be removed upon completion of
T319356.
* Conditionally renders the learn more link based on whether
$userMenuData['is-empty'] is `true` so that we don't show the learn more link
when the anontalk and anoncontribs menu items aren't present.
Bug: T317789
Change-Id: I883926c36f59d446076f960ead31f82e51967e70
All the images available in Fresh [1] include an npm version that
produces new-format lockfiles by default, so it’s actually not easy for
contributors to make any package changes *without* bumping the version.
Let’s just do it in a separate commit.
[1]: https://github.com/wikimedia/fresh
Change-Id: I42b2d0189c2cc1c20e4d1a05a6593a5ea421d060
We usually prefix the message keys with the skin/extension name,
and use label/help/tooltip as postfix when needed.
The naming of the tooltip above is limited by Linker::tooltip(),
so not able to rename it. Maybe some work is needed in the core.
Other languages' work will be follow-up by the translation bot.
Bug: T319447
Change-Id: I3c88871540b7668f1699fe3a86a8146f97ff5282
Preview width is set at 60em, but the container as a different
font-size to .vector-body and so the preview was displaying at
the wrong width.
This change removes the font-size from the grantparent and
re-sets it on the contents of #wikiPreview, ensuring that the
final size matches the actual non-editing width of the body
content.
In addition, the 'submit' action is added to the list of those
excluded from constrained width, so that the editing textarea
remains at full width even when previewing.
Bug: T312963
Change-Id: I1a1df32b00d5faecb73f8c53256342d356a9352c
