Page MenuHomePhabricator

When searching on en.m.wikipedia.org with iPhone, wrong result gets selected
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT

Description

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

  • Search for term on en.m.wikipedia.org with iPhone
  • Keyboard should be open
  • Click on first search result (it helps if you press on the bottom half of a search result)

What happens?:
Second search result is selected

What should have happened instead?:
First result should have been selected

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:
Video:

iPhone 12 Pro Max (MG9J3LL/A)
ios 15.2.1
Safari browser (version tied to ios version)

Event Timeline

Aklapper renamed this task from When searching on en.wikipedia.org with iPhone, wrong link selected to When searching on en.wikipedia.org with iPhone, wrong result gets selected.Jan 23 2022, 4:31 PM
ovasileva moved this task from Not ready to estimate to Groomed on the Web-Team-Backlog board.
ovasileva subscribed.

Declining for now as the issues is only available within the Vector legacy (2010) skin. Can confirm this is not occurring when using the new search widget within the Vector (2022) skin. @SCEhardt - you can switch to the new version of the skin within the appearance section of user preferences

Sorry but I can't see a difference (video). Can you advise?

Aklapper changed the task status from Open to Stalled.Mar 1 2022, 6:09 AM

(Mobile (en.m.wikipedia.org) doesn't use Vector skin but Minerva skin?)
Last video shows that second result gets selected (!) in the browser, here is a still from your video:

Screenshot from 2022-03-01 06-59-37.png (713×332 px, 144 KB)

I'm not yet convinced that this is a server-side issue. Can you/anyone reproduce on other devices or browser versions?

ovasileva raised the priority of this task from Low to Medium.Mar 1 2022, 9:40 AM

My bad, I thought this was happening on en.wikipedia.org vs en.m.wikipedia.org. Can confirm reproduction in Safari although it's not consistent (get correct result about 50% of the time)

SCEhardt renamed this task from When searching on en.wikipedia.org with iPhone, wrong result gets selected to When searching on en.m.wikipedia.org with iPhone, wrong result gets selected.Mar 1 2022, 2:20 PM
SCEhardt updated the task description. (Show Details)

Thanks, yes-- I'm not sure how to display finger taps in the video, but I tap the first result and the second result gets highlighted. Sorry for any confusion; I updated with the correct address including m

Jdlrobson changed the task status from Stalled to Open.Mar 7 2022, 9:42 PM
Jdlrobson assigned this task to ovasileva.
Jdlrobson subscribed.

I have been unable to replicate this on browser stack with any of the iPhone Pro Max devices.

@ovasileva analyzing/debugging this will need to be done by someone with the actual physical device (and be a context switch). Do we have such a person? If not, it might require ordering one of these devices.

Time might be better spent working towards T282473.

@Jdlrobson - I can reproduce on an iphone 11, Safari 15. @Edtadros - can you try with your physical iphone 12?

I'm trying to get hold of a device to replicate this one so there might be a delay in analysis for this one.

I believe this is happening at least partially due to Safari's behavior of automatically scrolling the webpage when opening/closing the keyboard. It happens very fast, but you can reproduce by clicking on a search result with the keyboard open:

  1. the keyboard will close
  2. the page will scroll up slightly
  3. your click will go through and likely hit the next search result.

This issue doesn't happen if you close the keyboard before clicking a result, or if you make sure to click to very top of a search result (because the amount the page scrolls up is small). However, I'm unsure why the click is being affected by the scroll. When looking at medium's search on small browser, you also see the scroll happening on keyboard close, but it doesn't impact the click. Perhaps our overlay implementation, our use of fixed position, or the particularities of how our input is unfocused could be impacting this?

Others have tried to deal with this Safari behavior, (1, 2, 3), and it seems hypothetically we should be able to write some JS to counteract this. However, I haven't been able to test how feasible that is, as I haven't yet figured out how to get my localhost on my phone yet. More research is needed here

@bwang Agree 100% with your assessment

I noticed that medium.com/search doesn't close the keyboard when you tap "return" (And for that matter, the button says "return" on medium but "Search" on Wikipedia). Maybe this makes the difference.

Also, the search gets really crazy if you tap Search within pages and then go back. But this is probably a separate bug.

@SCEhardt I filed another task to capture the Search within pages issue. https://phabricator.wikimedia.org/T304445

Change 773362 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] [search] Prevent scroll when keyboard opened

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

I managed to get a physical device and it's as you say it is @bwang. With some Safari debugging I've worked out that if we stopPropagation for touchstart events on these clicks the problem will go away. Moving to estimation.

nray set the point value for this task to 3.Apr 6 2022, 4:57 PM
nray subscribed.

Voted this as a M mostly due to work involved in actually replicating this (need an iPhone) but also because there may be unintended side effects involved with stopPropagation or preventDefault

For whoever picks this up, this guide was helpful for getting localhost and web inspector on an iPhone.
In order to get localhost on your iPhone you also need to set $wgServer in LocalSettings.php to be your IP address

Change 773362 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] [search] Fix bugs

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

reassigning because I simply cannot reproduce this.

Jdrewniak subscribed.

I tested this today on production and I'm not seeing this issue anymore, so I think the solution looks good :)

ovasileva claimed this task.