Page MenuHomePhabricator

Reversed ordering of autocomplete suggestions in search bar in mobile Wikidata Firefox
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

  • Go to https://m.wikidata.org/ (let’s say in a private window in Firefox, to be sure)
  • Write something reasonable into the top search bar; let’s say obama.

What happens?:
Notice the autocomplete results start with many less important items without an image (some Obama’s ancestor in Q96197836, fictional spy car in Q91269986, …), and, finally, at the very end, the 44th president of the United States (Q76).

What should have happened instead?:
Barrack Obama is an obvious candidate to be the first autocomplete suggestion for the “obama” query; definitely it should not be the last result.


The order of autocomplete suggestions for mobile search on Wikidata is so obviously wrong I have sometimes sadly remarked it seems they are shown reversed. I did not know this was literally true! The client-side mobile frontend displays the results in a reversed order than what it has received from the search API! (It seems unbelievable nobody have reported that yet, but… I guess everyone is so used to less-then-stellar quality of search on Wikimedia projects… Dunno, but I could not find an existing report for this.)

Developer notes

The order of autocomplete suggestions is inconsistent between Firefox and Chrome and should be consistent

QA Results - Prod

ACStatusDetails
1T307601#7997359

Event Timeline

Change 789220 had a related patch set uploaded (by Mormegil; author: Mormegil):

[mediawiki/extensions/MobileFrontend@master] Fix search result ordering

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

Oh, great, that at least explains why I’m the first the report and fix this.

Yeah, the implementation-defined behavior of array.sort when given an inconsistent comparator (I mentioned it in the commit message) is obviously in play here: I’m using Firefox where the sort results are reversed, while in Chrome, Chromium-based browsers (I tested Edge), and in IE, the “always return +1” broken comparator results in the original sorting order (while “always return -1” results in the reversed order).

You can try [1,2,3,4].sort(function(){return 1}) in a browser console: Firefox gives [4,3,2,1], Chromium and IE give [1,2,3,4].

Jdlrobson renamed this task from Reversed ordering of search results in mobile Wikidata to Reversed ordering of search results in mobile Wikidata Firefox.May 5 2022, 3:17 PM
Jdlrobson updated the task description. (Show Details)

The proposed patch makes sense to fix this. I'd want us to thoroughly test this on production data on several projects with some real data though before merging (we can do this by passing a production domain to the mw.Api parameter)

ovasileva triaged this task as Medium priority.May 5 2022, 3:49 PM
MPhamWMF renamed this task from Reversed ordering of search results in mobile Wikidata Firefox to Reversed ordering of autocomplete suggestions in search bar in mobile Wikidata Firefox.May 9 2022, 2:20 PM
MPhamWMF updated the task description. (Show Details)
MPhamWMF added a subscriber: MPhamWMF.

Updated ticket to reflect that this is about the order of autocomplete suggestions, and not (full text) search results (these are two different processes on the backend -- yes, this is a little confusing and should probably be addressed elsewhere)

Change 789220 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Fix search result ordering

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

The fix seems to work fine in production. Should I close this as fixed, or is it going through some process on WMF side?

Edtadros added a subscriber: Edtadros.

Test Result - Beta

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

Test Artifact(s):

QA Steps

❌ AC1: The search results should be in order of most obvious candidate to last.

Screen Shot 2022-05-26 at 6.15.16 AM.png (1×1 px, 80 KB)

Screen Shot 2022-05-26 at 6.16.47 AM.png (992×981 px, 63 KB)

Screen Shot 2022-05-26 at 6.18.14 AM.png (1×834 px, 69 KB)

Screen Shot 2022-05-26 at 6.16.33 AM.png (356×975 px, 27 KB)

@Edtadros thanks for checking this. It looks like the beta cluster search response differs from the production API in that it doesn't return an "index". I presume this is missing some production infrastructure and not production like. I would suggest noting this as "Not possible to test on beta cluster" and run the test again in production (it sounds like it's fixed).

Test Result - Prod

Status:
Environment: enwiki
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

❓ AC1: The search results should be in order of most obvious candidate to last.

@Jdlrobson, when I type things correctly...

Screen Shot 2022-06-02 at 9.48.09 AM.png (636×590 px, 142 KB)

Screen Shot 2022-06-02 at 9.48.30 AM.png (609×559 px, 129 KB)

However, when I misspell something (admittedly not on purpose)...the order is not right, but coincidentally what I was trying to spell ended up on top. I was expecting an alphabetic list. Any idea what's going on here?

Screen Shot 2022-06-02 at 9.49.34 AM.png (636×625 px, 143 KB)

@Edtadros for production we only need to test mobile (Minerva) Wikidata. The screenshots here are desktop Vector Wikipedia. I don't think we need to do any extensive QA here other than to verify Obama is the top search result on Wikidata for the Obama query.

The order on Wikipedia is based on a lot of things - in production we have spelling correction for example so I wouldn't dwell on it too much. It should be ordered by relevance to the query not alphabetical.

Test Result - Prod

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

Test Artifact(s):

QA Steps

✅ AC1: The search results should be in order of most obvious candidate to last.

Screen Shot 2022-06-12 at 5.29.18 PM.png (865×435 px, 168 KB)

Screen Shot 2022-06-12 at 5.29.01 PM.png (884×429 px, 128 KB)

Double-checking on firefox - looks good!

Screen Shot 2022-06-13 at 8.58.27 AM.png (1×892 px, 224 KB)