No longer needed now that the underlying cause has been fixed.
This reverts commit 5bcc1597ca.
Bug: T327229
Change-Id: I69ae0634446ea546a1d221932caf3e61bebaa6d0
Depends-On: I71f1cc0d08bfd02e1a9edb6cbfd849f10f929f3c
Clicking the bolded text in the search footer didn't work. This change
fixes that by working around the underlying issue, rewriting the search
footer template to use v-html instead of v-i18n-html. I don't know
exactly know why this works, but it does. Hopefully we'll be able to
fix the underlying issue and undo this workaround in the future.
Bug: T327229
Change-Id: I5d05d6ade1a34b12163bb96aa888ed3cfee78b4d
As far as I can tell, this has been dead code ever since it was
introduced in change Ica040cd18d (commit aa10668e6d), and was never
called; the effective search URL was initially constructed via inputs to
the search form (e.g. a hidden input for wprov), and later the separate
urlGenerator.js was added. (Also, “suggestion” is not a valid
Special:Search paramater as far as I can tell.)
Also add some tests for the separate urlGenerator.js, to make up for the
other tests being removed.
This reduces the module size of skins.vector.search enough that we can
decrease the bundle size test config to 3.2 kB [KiB].
Change-Id: I6be5ba362402c2c2ec582d9a0192c80f46e7a7ce
If the wgVectorSearchClient supports it (the default implementation
doesn’t), add a visible-item-limit to the cdx-typeahead-search, and wire
up the resulting load-more event (new in Codex v0.3) to load additional
search results on scroll.
The hard-coded visibleItemLimit (7) is chosen to match the default limit
of the wbsearchentities API, but ultimately arbitrary; we can look into
how to make this number configurable later, if necessary.
This increases the module size enough that we need to bump the bundle
size a bit more.
Bug: T322333
Change-Id: Iadade9cbf48457cfeabc78439624602ec3f98782
Co-Authored-By: Jon Robson <jdlrobson@gmail.com>
Needed-By: I67fac3b209d6a1ab2661e1e1c0681edd8472ac6c
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 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
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
This allows the URL to the other wiki's rest.php to be configured
exactly, rather than assuming that it has the same wgScriptPath as the
current wiki. This is necessary to make this feature work on PatchDemo,
where wgScriptPath looks like '/123abc456/w'.
$wgVectorSearchHost is removed, since nothing uses it except PatchDemo
(where it's broken) and development setups.
Bug: T319494
Change-Id: Ife042f4f683d366a31a642723746d4aa80774c03
Change I765d3bbf89 pushes the module over the configured maximum allowed
size (3 KiB, see bundlesize.config.json); shave off some bytes elsewhere
to bring it below the limit again. IMHO all of these changes should be
acceptable:
* arrow functions are already used elsewhere in this module;
* using the mw.config.get() fallback argument is normal (it slightly
changes behavior, but I don’t think explicitly setting the search
client or URL generator to a falsy value and expecting to get the
default behavior should be considered supported);
* not quoting [name="search"] matches [name=title] immediately above;
* using forEach() with a function reference is still readable (initApp()
is now called with extra arguments, but that doesn’t matter).
Change-Id: I45dda26cb59279d91804b0c2bbf12174fa78ee12
This class is no longer needed in Codex and will be removed.
This patch adds a similar dynamic class to the Vector search
app, to be used for showing/hiding the search button on
focus/blur or hover/leave.
Bug: T316893
Change-Id: I738c0f24dcd06ddeb9179cfedc85ed73a6504f1e
This doesn't change any behavior, it just suppresses a compatibility
warning and ensures that future changes to this file won't introduce
code that relies on Vue 2 compatibility features.
Change-Id: Id15af7d5d5035f59dc8f402f00d8f7f0d73a77f7
[Visual changes]
This should result in 9 visual regression failures relating to
increased height of search results and loading bar
[More details about change]
- Migrate search app from Vue 2 to Vue 3; update tests
accordingly
- Remove dependence on WVUI and use Codex instead, via the special
`@wikimedia/codex-search` package
- Update search app to use CdxTypeaheadSearch, which no longer
takes in props related to the search client or fetch start/end
instrumentation. Instead, directly use the restSearchClient
and call fetch start/end events in the search app.
- Handle hideDirection in the search app/API response formatting
code, not within the TypeaheadSearch component
- Handle showing/hiding the search button in the app
- Move the WVUI URL generator into Vector
- Update server-rendered search box styles to match design updates
included with CdxTypeaheadSearch
- Replace references to WVUI with references to Codex
- Update values of various LESS variables to match Codex, and update
searchBox styling to prevent jankiness when the searchBox is replaced
with the Codex TypeaheadSearch component
The VectorWvuiSearchOptions config variable has been maintained and
will be updated to a code-agnostic name in a future patch.
Bug: T300573
Bug: T302137
Bug: T303558
Bug: T309722
Bug: T310525
Co-Authored-By: Anne Tomasevich <atomasevich@wikimedia.org>
Change-Id: I59fa3a006d988b14ebd8020cbd58e8d7bedbfe01
Rather than test for fetch, limit the code to ES6 browsers.
Depends-On: I96a03796628a74ace93579d45a582711400c09c1
Change-Id: I4ca10182491118e61e155f99c713d4cb1b4fc7f0
Vector's tsc version is currently reporting errors that the latest
typescript version doesn't report and vice versa. Upgrade to the latest
version to avoid these discrepancies.
Additionally:
Fix tsc errors that are now reported by updated version
Bug: T297614
Change-Id: I0eb67bcc1a5ce214fcf2d6f6433a5de3a845b6a6
In preparation for I30c670e3f195f77a27715c6b494a3088b7a55712, refactor
the search component expand behavior so that it can accomodate the new
changes in WVUI while maintaining backwards compatibility with the
status quo.
Additionally, pass/enable the `auto-expand-width` prop to the main
header's search. This will be inert until the new changes in WVUI have
landed.
Bug: T297531
Change-Id: Id8d3bd4aa74113b91ecaf66cb58cf5625db8a302
Follow up to 5dee570cb2.
It seems the mount works slightly different in that it creates a div,
appends by the App element to the element you give it, after
clearing all it's child nodes.
The previous behaviour was that the old element was /replaced/
by the App element.
Bug: T296889
Change-Id: Iee7493c032f4de5389207bba288a1a70e4cd14f3
- Create new 'vector-searchsuggest-containing' translation for WVUI search footer text
- Use 'search-footer-text' slot in WVUI typeahead search
- Remove instances of old 'footerSearchText' prop
Bug: T290392
Depends-on: I8fb7761e60be330e58cd017872318fe3675c0be1
Change-Id: I9c946f85c3e4a603c362c3ea4b8016c585cdd212
Port the initialization code for the Vue search to use Vue.createMwApp()
instead of new Vue( ... ). The former mimicks Vue 3's API for mounting
components.
Without this change, this code breaks in Vue 3 (even in compatibility
mode) because the compat support for new Vue(...) is imperfect. By the
time renderFn is called, the searchForm container has already been
emptied by Vue's internal mounting code.
Instead, inspect searchForm and generate the prop list before mounting,
then pass the props to createMwApp() and mount the component.
Bug: T294476
Depends-On: I1fcdcf7bf87f5af2deb9763a231f2c360ea45b23
Change-Id: I5b6e66051d97e75f8f03b8258894daba22525797
- Create new 'vector-searchsuggest-containing' translation for WVUI search footer text
- Use 'search-footer-text' slot in WVUI typeahead search
- Remove instances of old 'footerSearchText' prop
Bug: T290392
Depends-on: Ic92721d5aaf6b833c882a26e9a60b42ab91546fa
Change-Id: I34a184cc8f10172a7ebf67981731c3694d008446
Styling should not depend on IDs to allow us to have multiple
searches in the page.
Precursor for wiring up search in the sticky header.
This also tweaks performance metrics to track separate metrics
for the sticky header search
Change-Id: I5b4192a8f5a9f95af26c1faf904f7cc994323518
Per T289724#7342741, server renders an anchor tag pointing to #p-search
into the "button-start" bucket of the sticky header.
In the future after T289718, this anchor will then acts as a button when
the search module is loaded and searchToggle executes.
* skins.vector.search was modified to accomodate instantiating multiple
search components (one in the main header and one in the sticky
header).
* searchToggle.js was modified to accept a searchToggle element as a
param which the caller can then instantiate when ideal. For the sticky
header toggle, this needs to happen *after* the search module loads.
Before then, the toggle will act as a link.
* Drops one jQuery usage from searchToggle so that it can be jQuery
free. Because the native .closest method is used, IE11 support is also
dropped. However, the script feature detects and returns early if the
API isn't available.
* Makes App.vue accept an `id` prop so that multiple instances of it can
be created.
Bug: T289724
Change-Id: I1c5e6eee75918a0d06562d07c31fdcbd5a4ed6d5
... for the WVUI search autocomplete widget.
The VectorWvuiSearchOptions object is sent to the client whole and
already used as the base props for the app component constructed in the
skins.vector.search RL module. We also define the highlightQuery prop on
that component so that its value can be passed to the WVUI
typeahead-search component.
Bug: T281797
Depends-On: I142810c177b850ecd7015f835bb6630bae00a6ea
Depends-On: Ia5e14fb9d0073a5126a0918f7a94213c671e773a
Change-Id: I551414b111226e690f6a2bc69dabf5edc6fb0a96
Eslint is throwing compat warnings on every commit in Vector. This
commit silences those warnings.
Change-Id: I0e914c6179745415e916fadd382d86baa72e3e63
The parameters passed to the typeahead-search Vue component don't need
to be escaped, they're already escaped by the Vue implementation. Use
.text() instead of .escaped() for the i18n messages passed to this
component, to prevent them from being escaped twice.
Change-Id: I5dcf442f6af181a99123bf7426743af01b097729
The #p-search element is present in at least the Vector, Vector V2,
Timeless, and Monobook skins. This is because the HTML for the element
is generated in MediaWiki Core. At the very least, the
SearchSatisfaction instrument relies on the element always being
present.
Update the skins.vector.search module to simplify the App component
template so that it doesn't render a div#p-search element and mount that
component on the #searchform element instead.
Bug: T274869
Change-Id: Ifde679b62484fda7661fded2d978b78adac9f5da
```
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
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
