SkinMustache in core provides most of what is required for Vector to
generate its menus. In the interest of having a canonical source of
truth for menus across all skins, Vector should use this data.
To ensure the HTML generated is (mostly) the same after this patch to
prior, a few modifications are necessary:
* The data from core is decorated so that Vector can continue having its
own custom class names on menus. This is done using the
decoratePortletClass method.
* There is no support for a menu having a header representing the
selected menu item, as is currently the case with variants. This is
achieved via an extension to getPortletData. It's assumed that later
when variants are merged with languages, this can be removed.
* Menus are agnostic to how they are displayed, so we must continue to
add the is-dropdown template variable to drop down menus. In future we
may want to rethink our Menu partial to make this unnecessary in PHP.
* The portal-first class is redundant in the modern Vector as we can
use the first-child selector. Previously we introduced a class to
service the legacy skin where this rule doesn't apply as #p-logo is
the first child. However, the legacy skin can do this using a special
next sibling selector instead.
Bug: T268157
Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
```
mw.config.set('wgVectorSearchClient', {
fetchByTitle: function( query, domain, limit ) {
var xhr = fetch('http://' + domain + '/w/rest.php/v1/search/title?q=banana')
.then(function (resp) {
return resp.json();
}).then(function (json) {
return {
results: json.pages
}
});
return {
fetch: xhr,
abort: function() {}
}
}
})
```
This should be the absolute minimum to allow API clients to configure
the search. This should be considered an interim solution to buy us time to work out a more
elegant way to do this e.g. do this in the API itself…
Bug: T262566
Change-Id: Iac6f2551bed911980064dcb023193f800df0934f
`#mw-searchButton` is apparently used with no-js clients or if the
js-search is broken [1]. Its position and dimensions should be kept in
sync with #searchButton.
This commit:
* Ensures that the same styles, including position, applied to #searchButton
are applied to "#mw-searchButton" so the dimensions are identical. This
should also address a critique in T270202 by removing the "invisible
button".
* Applies a `client-js` selector to ensure these buttons are
only positioned to the left of the search input if js is enabled. If js
is not enabled, having these positioned to the left is confusing as the
input has no obvious "submit" button.
* Syncs the input's end padding to match WVUI's input's end padding if
JS is enabled.
[1] 465e9492bb/includes/templates/SearchBox.mustache (L12-L21)
Bug: T270202
Change-Id: Ie1bb8c68b713b3a18f90ee11b44c78b436a6d0ba
Per T270202, there should be no underline on hover. The underline is
coming from a style in core.
There should also be no bottom margin on the suggestion li elements. The
bottom margin is also coming from a style in core.
Bug: T270202
Change-Id: I215a41aa328366aee2bb552d5d49c95905fd37f2
Following Design Style Guide components sizing and Alex' feedback
on task. Changing applied styles scope to non Vue.js enhanced,
modern-only style of search component as well, in order to have
clean appearance and transforming disruption free.
Also changing em static values to LESS calculations for more developer
friendliness and change background-size to be `em` as well for
user-set typographic zoom preference ability.
Bug: T269959
Change-Id: I157712721621344171a32a8887a5e20cc16cae0d
`@margin-horizontal-search` is used for margin of search component
and for personal tools, but they are also floated right so one only
gets a clearer picture of this change when the canvas is exactly at
one specific size.
Additionally it's used for a media query, so the min-width is slightly
reduced (by 32px equivalent) as well. That's advantageous too.
At some point we're going to change this to `rem` unit, that's why I've
taken distance from changing it to a `px` value for now although devised
differently before.
Bug: T269959
Change-Id: I21cac3f049eed64520dd229ef80d10f9be853e0e
Modifies and annotates the CSS required to make the server-rendered
version of the new search form look like the WVUI version of the
search form.
Bug: T264355
Change-Id: I989860cfbb755ecbb706b79bd807e9d0013bc4e5
This is almost identical to the instrumentation currently used in
production for mediawiki.searchSuggest -- the only differences being in
the nomenclature of variables, etc.
As part of comparing Vue search with legacy search, we need to track how
long it takes a keypress to load and render search results for Vue
search. This will only be used only in synthetic testing at this time
(Real user monitoring (RUM) is not in scope for this ticket).
To test locally, first enter characters in input. Then to see the
metrics recorded:
```
// View all marks
performance.getEntriesByType('mark');
// View all measures
performance.getEntriesByType('measure');
```
This commit adds the following metrics which will only be used in our
synthetic tests. We are not collecting RUM metrics at this time.
Measures:
* mwVectorVueSearchLoadStartToFirstRender: Measures the time it takes
from the start of loading the search module to the first render of results.
* mwVectorVueSearchQueryToRender: Measures the time it takes from
the start of the fetch to the render of search results.
Bug: T251544
Change-Id: I39200648a3a0a4079a132134d142ad8997c8962a
Add event listeners and associated helpers to emit SearchSatisfaction
events via the `mediawiki.searchSuggest` protocol.
Bug: T257698
Change-Id: Ica040cd18d6c4bf8a1b1f607bb4647c7e8eb7108
By default the API uses location.host as the host, however during
development it is useful to test against production wikis
For example to test against English Wikipedia:
$wgVectorSearchHost = 'en.wikipedia.org';
Note: Links when clicked will not take the user to the target page, and
instead will take the user to the search results page with a link to
create the page.
The following config can be used to workaround that page:
$wgDisableTextSearch = true;
$wgSearchForwardUrl = "/w/index.php?title=$1";
Change-Id: I5fbac7f54844d7a9d6976007bc0d0ff9938b9f2b
Uses ResourceLoader's virtual config feature to get the config and pass
it down to Wvui's typeahead search component.
Disclaimer: I'm a typescript noob and am not sure if the
config.json.d.ts is correct although it seems to make tsc happy.
Bug: T260167
Change-Id: I2eced14c7df3b795b4de0e5149c2ca9fd598c7be
Creates a new skins.vector.search module that
replaces the searchSuggest module from MediaWiki core.
This module creates a new Vue app using the WVUI
search widget for the new search experience.
The legacy search input form is still retains on pageload,
and the new search kicks on search input focus.
In order to manage that transition, the legacy search
input is styled to resemble the new WVUI input, and the
new input is manually focused after the component mounts.
Vue is also added as a dev-dependency to help with
type-checking.
Other changes:
* the entry in skin.json is reordered alphabetically after
skins.vector.js
Bug: T264355
Change-Id: Ibb9561a77a14734297cb4d0ddcd415fc0750b45d
Updating 'search' icon to latest WVUI/OOUI optimized, reduced path. Also
- amending size of search input and position of icon in input slightly to
align it closer to standard text inputs
- simplify CSS by getting rid of selector which is targeting both, input and
button and applying rules only where needed
- fixing code comments
- increasing icon size to `16px` equivalent `em` to enable user text zooming
preference applied to search icon as well. `16px` is a compromise towards the
old look and feel of the previous icon bringing it closer to standard icon size in
legacy Vector.
This change affects both modern and legacy versions of Vector.
Bug: T266166
Change-Id: Ib4c0c74d3cac30e1893f4c76e56e1197652d41ba
Replaces vector search icon with an update version that is
copied from the OOUI icon set and used in WVUI search.
This update will help us unify the visual appearance of the
existing search input with the one in WVUI.
Bug: T264355
Change-Id: I34792ee80e711b10b441668cc4ae18cc0cc9daa6
There are popovers such as the discussion tools "Add a link" popover
that need to stack on top of the footer. This replaces the
mw-footer-container's `relative` positioning with `static` positioning
which is one possible solution to this problem.
Alternatively, the popover could be appended to the end of the body
after the footer and positioned absolutely.
Bug: T264679
Change-Id: I34168c181a1e05c33cd42f664fcccb25abd4519b
An only-child will match first- and last-child selectors
so this additional selector is not required.
Change-Id: I17d468ba2bda37edc4e54f42f42d50e4b8831b46
Following-up Iecb0d6c4c80cee1d1684597a6dedf7323e2ec54d.
It isn't set anywhere inherited, hence we don't need to set it here.
Change-Id: Ife24aa95e6d1830b8d50001976277dbb2535c47f
Dropped all usages of the no longer applicable `skin-vector-search-header-legacy`
class.
Bug: T258116
Change-Id: I16a5cf8dda2ab84ff4b505d5a368587190c409cd
Unifying blockquote spacing and border style with Design Style Guide.
Also ensuring that blockquote children don't apply inherited whitespace.
Bug: T265947
Change-Id: I43a6951c17376fe3fdd4d24966ec4661c18ffd87
Uses flexbox alignment to resolve an issue where the
clickable area of the notification and alert icons were
overlapping with the links next to them.
Bug: T264339
Change-Id: I2afc12504d7184583fa8331479125474c68017dc
Now the header is no longer absolutely positioned the height is not
fixed and the personal tools can safely spill onto a new line
Bug: T264206
Change-Id: Ib2a3cf1907c7d06c2c92ccbd902a98a3f8242f37
Follow up to 6d967ed4a8c
Add the missing ! to check that the portal is hidden rather
than visible to restore the correct logic.
Bug: T71729
Change-Id: I29f6f5e1e6adf3d6d9795cbdabcc152c5d5ac28f
On the long term we want to provide access to these variables in other
extensions. e.g. VisualEditor
Bug: T259331
Change-Id: Ibbc6f1905ea384a3d159088e3f5eca947eb6ec08
As part of comparing Vue search with legacy search, we need to track how
long it takes to lazy load the wvui library. A similar metric was added
to measuring the mediawiki.searchSuggest module in
I0fa6b8904bd43c87a68e9161f00d686a0e588966.
This commit adds the following metrics which will only be used in our
synthetic tests. We are not doing RUM tests at this time.
To test locally, add the following to your LocalSettings.php and append
the query param `useskinversion=2` e.g.
(http://localhost:8181/wiki/Test?useskinversion=2):
```
$wgVectorUseCoreSearch = false;
```
Marks:
* mwVectorVueSearchLoadStart: Marks the start of loading the search
module.
* mwVectorVueSearchLoadEnd: Marks the end of loading the search
module.
Measures:
* mwVectorVueSearchLoadStartToLoadEnd: Measures the time it takes to
load the search module.
Bug: T251544
Change-Id: I14e44b45a66213821d69cd22395fedbae747da88
Drop support for vectorMenu, vectorTabs and
vectorMenuCheckbox, body, menu selectors in preference
for standard selectors.
This change will impact a large amount of user scripts/styles but should
not impact any gadgets.
These classes were kept around for user scripts and styles however are not
needed internally. As we transition to a more maintainable skin menu
system, it is time to lose these selectors even though this will cause
disruption.
Vector now will use the mw-portlet class rather than the vector-menu
class in its own CSS styling, however it keeps the other classes to
allow differentiation of the different types of menu.
Changes to test: Previously the tests assumed all portlets were empty
when checking the classes. This is very rare, so its better to check
the classes of non-empty portlets, so several tests are updated
accordingly to drop the emptyPortlet class.
Bug: T262092
Change-Id: I1824335eb47d613c2a4804ec1f1106c0f4c16101
Kept as simple as possible for now. The new class is added but no classes
are removed. This will be done in a follow up.
Bug: T256897
Bug: T253938
Change-Id: Ib31a9d8f2ac14e63b63e82abd4a9aa1fcb956f45
jdlrobson
Nicholas Ray
Volker E
Jan Drewniak
jenkins-bot
Sam Smith
Ed Sanders
Timo Tijhof