| Jidanni | |
| Sat, Nov 8, 9:22 PM |
| F70278762: screen recording.webm | |
| Tue, Nov 18, 6:51 PM |
| F70025830: Screenshot 2025-11-09 05.11.34.png | |
| Sat, Nov 8, 9:22 PM |
Steps to replicate the issue (include links if applicable):
What happens?:
Suggestions taken from sitewide user list.
What should have happened instead?:
Suggestions taken from participants user list first.
Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):
GitHub gets this right.
Upstream: https://we.phorge.it/rP670a9a182a65ff6fc16b0fe2ffec27f983b6cd05
This ticket got resolved today as part of the Phabricator upgrade in T409947. See J322 for a full list of changes.
I'm not personally sure if this is fixed -- testing it out just now on https://phabricator.wikimedia.org/T394111, it takes me typing three letters of @Reedy's username (the only subscriber to that task whose username starts with an R) before it appears in the autocompleted list.
Given the huge amount of usernames that we have here and the algorithm in https://we.phorge.it/source/phorge/browse/master/webroot/rsrc/js/phuix/PHUIXAutocomplete.js , indeed this does not always work immediately for all expected results on the first character(s) entered, as result paging is involved, and only afterwards sorting to the top. The alternative would be running two queries, which is worse performance-wise. :-/
How about only if no matches in the thread are found then begin a query. All the thread internal matches could be kept around in a local variable. And only if the user has typed something that couldn't be matched already, only then send a query over the network.
I currently cannot prioritize rewriting how the typeahead proposals framework in Phorge works but I'm sure that upstream at we.phorge.it welcomes improvement patches!