When the existing search results don't contain an exact match
(see previous patch), perform an additional search for the
title. This uses OpenSearch. This is recommended in multiple
places and also used in the quick search field at the top of
MediaWiki.
Again, I came to the conclusion that an isolated unit test
would be complicated and not test much anyway. Better test
on-wiki.
Bug: T274903
Change-Id: Ib575248e089ff66814400202d224deff6369c772
This code detects a few edge-cases:
1. When some search results are exact matches, make sure they
are always at the very top.
2. When the prefixsearch API is used, e.g. as a fallback,
redirects show up as a separate metadata structure outside of
the pages array. Consider these and stop if there is already
an exact match.
3. CirrusSearch returns redirects as part of the pages array.
When there is an exact match, make these redirects separate
options and add them to the top.
All of this is case-insensitive, on purpose. In case two
templates with different capitalization exist, we rely on
the backend to return both. The code introduced here is fine
with this.
Notes:
* This doesn't guarantee an exact match is always there. This
requires an additional HTTP request and is done in the next
patch.
* I tried to write unit tests for this, but gave up. The setup
is complicated. An isolated unit test would not test much
anyway. Better test this on-wiki.
Bug: T274903
Change-Id: I64e1b5633e7b878a4d0d23d66229ca87e69d0045
These are the most minimal (and therefor most stable,
hopefully) hacks I could come up with so far.
Bug: T274903
Change-Id: I28ba414dd34aad756e29400eb656f0942291a923
New changes:
aea74f1ae ui.actions: Move var statements inline
beb396899 IndentationAction: Refactor case runner
80379d8b2 IndentationAction: Add coverage for slug edge case
8d24c0a82 build: Updating browserslist to 4.16.6
55460cee6 utils: Move var statements inline
8592347e3 ve.ui files: Move var statements inline
ab2cf84d2 IndentationAction: Handle 'increase' when in a slug as well as 'decrease'
0470dddf6 IndentationAction: De-duplicate increase/decrease methods
c16ca4363 IndentationAction: Complete coverage
Change-Id: I95fd8022a07b3c7bec316498e0dc255144e584f1
New changes:
e117cd238 Call contextItemFactory.lookup, not contextItemFactory.registry.lookup
2b81a0b7b Deactivate selection on mobile while in read-only mode
e9a8ff887 Actually handle inTargetWidget config
Bug: T281771
Bug: T282194
Bug: T283445
Change-Id: Ied3e94bc3ebd2b390d9832215a94893fce64a5d3
New changes:
adb902514 Localisation updates from https://translatewiki.net.
d1af2fd53 Dist: Update language lists
Change-Id: I7c32537d3387c4d542842d9f10832db774573b6c
* Create getSurfaceClasses method.
* Pass surfaceClasses to target widgets.
This ensures that the 'content' class is passed to mobile
target widgets, and the 'mw-body-content' class is added
in a less hacky way.
Change-Id: Ibce6d1a1d0fda63cca354761f1b91f808858e95b
Template names sometimes show up twice when searching for a
template in the "Add a template" dialog.
This is a bit hard to test. The code responsible for this
is not in a single place. The feature is in the upstream
TitleWidget class. It's not broken. It makes sense to
provide e.g. "foo" and "Foo" as two separate options when
the user typed "foo", but the page is named "Foo". Both are
valid, and the feature allows the user to pick either.
But the VE widget does it's own normalization. Both entries
are normalized to "Foo". Both do the same. The additional
one is pointless.
You can try this on the actual enwiki: Open VE, insert a
template, search for "Template:nHLE".
Change-Id: I65e706c4d131a2f8c605d7979a02ea56f831bf03
The "redirects" part in a prefixsearch query is always an
array, no matter if formatversion 1 or 2 is used.
The "pages" part is an object with formatversion 1, and an
array with formatversion 2.
As of now this always uses formatversion 1. This is
hard-coded in the upstream TitleWidget class.
Change-Id: I8cde8e104f8a288015da745db41016f6639b453b
This reverts parts of commit
b72459409c.
Reason for revert: A user emptied several translations,
causing CI errors. The bogus edits are already reverted on
translatewiki.net.
Change-Id: I6600cb901953f99d363e14d2f41978ce9a447658
New changes:
5866b762f build: Re-enable Firefox testing
501e8354e ve.dm.Converter: Remove unused branch
84086e60f Localisation updates from https://translatewiki.net.
e1eb88ea2 Unify `list-style` CSS
d8eae968d ve.dm.Converter: Move var declarations inline
a26ff5fa6 ve.ce.Surface: Move var declarations inline
47a2d36f3 Localisation updates from https://translatewiki.net.
cf97b4938 build: Merge eslint main and html tasks back together
381ade44c build: Updating grunt to 1.4.0
d98f7995a Localisation updates from https://translatewiki.net.
c6bc154d2 Check if alien context item is registered before using
e645b06af Localisation updates from https://translatewiki.net.
58830c0dd build: Updating postcss to 8.2.15
f7b193a7e Localisation updates from https://translatewiki.net.
9730bd748 Update OOjs to v6.0.0
Bug: T240955
Bug: T282194
Change-Id: I7a26365a24103ac4e4b1279fda3b74ac6e4a9497
VisualEditor recreates the mw-body-content element. The element
with mw-parser-output already exists as a child. All skins now
consistently follow this pattern.
To limit the impact to the editor, we use ArticleTarget and add the class
to the surface, which corresponds to the mw-body-content element of a skin.
This avoids unrelated regressions in experiences such as DiscussionTools.
Bug: T283014
Change-Id: I4833d1ca9fda4fc0bd433760e47fe7010f00db05
