Page MenuHomePhabricator

"@" suggestions should come from participants user list first
Closed, DuplicatePublicFeature

Description

Steps to replicate the issue (include links if applicable):

  • Start "@"-ing somebody in Phabricator.

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.):

Screenshot 2025-11-09 05.11.34.png (731×544 px, 117 KB)

GitHub gets this right.

Upstream: https://we.phorge.it/rP670a9a182a65ff6fc16b0fe2ffec27f983b6cd05

Event Timeline

Izno changed the subtype of this task from "Bug Report" to "Feature Request".Sun, Nov 9, 3:22 AM
Aklapper changed the task status from Open to Stalled.Sun, Nov 9, 1:07 PM
Aklapper claimed this task.
Aklapper triaged this task as Low priority.
Aklapper updated the task description. (Show Details)
Aklapper moved this task from Backlog to Patch merged upstream on the Upstream board.
Aklapper moved this task from Backlog to Solved upstream on the Phabricator (Upstream) board.

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!