This has been added to the core behavior of shouldAbandon as well, but
the way it's overridden here needs to be changed since the
multiple-words check would override that.
Depends-On: If130cdc1df595e6ab12d531ce603cc42c8b3b5f3
Change-Id: Ie7bdc4a4702514fcb7d500924dad18729198b9e8
Also make our filter function match any substring of
the suggestion index (username + display names), as display
names often contain leading punctuation.
Bug: T266401
Depends-On: I69e5f54f7a8b7ca4126cc3ea513fc96e0a8606fb
Change-Id: I4e7429f8a88c3a82e981f37eb107c2b011482d73
Wikis like jawiki will then be able to customize the message to include
honorifics as they think appropriate.
Bug: T268588
Change-Id: I213fb9fd0a9ed6592ce3548a5b2c3b11a55c1abc
This causes the username to be selected on mobile, when
we want to place the cursor after it.
Bug: T294616
Change-Id: I29012ecd04cd553bf78ffff477babafacfeabb31
`this.limit` is never set, which mean the API default of 10
was used.
The client limit is actually `defaultLimit` which is set to 8.
Double this so we can filter blocked users and still probably
have some results.
Change-Id: I8184fa0ce1527280f4503bcf638372421287f51a
Such users will never be able to reply to you on most pages,
so we shouldn't suggest pinging them. The may be able to reply
on their own user talk page, but in that case they will be
included in localUsers.
In the best case they just clog up your search results, in the
worst case they are offensive names which haven't yet been hidden.
Bug: T294783
Change-Id: I2445ed6dc98c10f8580b2c36106dd3e98bb876d6
Since Id9afb2dd0212e4b871bb6a7a9d8762e1bcb81d6a included in core since
MediaWiki 1.38 the uppercase of the first character of the parameter
auprefix is not needed anymore.
Bug: T291339
Depends-On: Id9afb2dd0212e4b871bb6a7a9d8762e1bcb81d6a
Change-Id: Ic14ca9c9c61d2a50bdbaff50b56302a60ed17a96
We have logic above to exclude mentioning yourself, but this
is overridden if you are commenting on your own talk page.
Change-Id: I2858c79bd9f1cb733f105825e17f9df75859e40a
We can update the local filtered list before then, but then we would
have to do two updates for each keystroke, one to do an instant local
filter and another to back-fill the list when the remote results
become available. Currently CompletionAction is not set up for this,
and this might be confusing behaviour.
Bug: T256974
Change-Id: I6194cdcd6459be17fb142e644d73c9ec4036ba08
This is helpful when you ping the wrong person and need to correct your input.
Logically depends on I4c34e9368692b0ee4e7ca0f18ba2940406c62a9a
Change-Id: Iea89bdb5d93fe64902b692f04dd3a2e84e5517c3
The automatic event from core didn't catch this, because it's not an action
method called "open".
Bug: T255638
Change-Id: Ifa456e850a8edb374df098e21b46bb872416ae55
