FTR, this is not a beta-only issue (not that I was expecting that...): it's now reproducible on testwiki, which is on wmf.22.

The issue affects production wikis as well now. (confirmed at plwiki)

Not just a visual bug, they become unclickable too (the click always goes to the first element).

I believe this is happening because the id returned for special pages by the search API is not a unique value (it's 0 for all of them on enwiki), and we're using that id in the code as a unique identifier for menu items (both as an HTML id and as the menu item's value). The value is used in the Codex Menu component to determine which menu item should be highlighted.

If this is the case, the solution will be to change the adaptApiResponse() function in the Vector restSearchClient code to use something reliably unique for each menu item's id and value properties. We also might think about adding a validator to the Codex Menu component's menuItems prop to check that all items in the array have a unique value.

Typically we use -1 for special pages. I guess we need the platform engineering team's help on this one to change the value of 0 to -1?

In T313658#8166981, @Jdlrobson wrote:

Typically we use -1 for special pages. I guess we need the platform engineering team's help on this one to change the value of 0 to -1?

That won't help, because then all the special page results will have an ID of -1, and they'll still all be the same. I think the best solution would be to, as Anne said, have adaptApiResponse() detect that the page ID is 0 (which is also an invalid value, no real page will ever have a page ID of 0) and use a different, unique value instead. In api.php responses, results are keyed by page ID, and the server generates fake negative page IDs (-1, -2, etc.) for things that don't have real page IDs (special pages, nonexistent pages, etc). This code uses rest.php which doesn't do that, but you don't really need the server's help. You're getting the list of pages as an array, so you could just derive a negative number from the array index, with something like value: page.id === 0 ? -( index + 1 ) : page.id

Okay, so we'll update adaptApiResponse in Codex. Works for me.

Note that special pages are not the only kind of page that are either supported or should probably be supported in the future by search but don't have a page ID. E.g. we have global userpages which don't exist locally, or local copies of Commons file description pages, we want to make ArticlePlaceholders pages searchable eventually... so it would be great to have a general solution for handling ID-less results.

After talking to Roan the change here is required in Vector so this should be done by the web team: https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/2450fdeb99a00cba769b6f2e3b43d3fcf2eca863/resources/skins.vector.search/restSearchClient.js

Notes from Web/DST sync:

• Fix will be client-side, no PET changes necessary
• Will be a change within Vector, not Codex
• Web team will work on this

Change 826892 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Handle pages without ids in typeahead search

https://gerrit.wikimedia.org/r/826892

Change 826892 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Handle pages without ids in typeahead search

https://gerrit.wikimedia.org/r/826892

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

Open a wiki running the master version of Vector (beta will work)
Make sure you have Vector 2022 enabled
Click the search bar at the top and enter Special:A; wait for the results to appear in the dropdown
Start hovering on the results
✅ AC1: Each result has its own container element, and only that element is highlighted on hover.