Page MenuHomePhabricator

Selecting search results on mobile website in Firefox does not work
Closed, ResolvedPublic1 Estimated Story PointsBUG REPORT

Description

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

  • Enter arbitrary text into the search box on the mobile site while using Firefox for Android
  • Tap on a search result

What happens?:

Instead of navigating to the link, the search view will disappear. Opening the search bar again will show the text we entered (interestingly, tapping any result a second time does work).

What should have happened instead?:

The result that was tapped on should have been opened.

Other information (browser name/version, screenshots, etc.):

Tested on Firefox 133.0 on Android, which is the latest version. The issue did not occur in Google Chrome on Android, nor when using the Minerva skin on Firefox desktop.

Originally reported on Reddit by two users.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I came here to report the same issue. I've included my own screen recording. I had the same issue on the latest version of the MediaWiki software doing the test outlined on MediaWiki's How to report a bug > Can you reproduce the issue? article. The issue began sometime around Dec 1, I didn't note the exact date.

Machine information: Samsung Galaxy S22 Ultra, software version: One UI version 6.0; Version: S908USQS4DWLG S908UOYN4DWLG / S908USQS4DWLG; Size: 424.14 MB; Security patch level: January 1, 2024. Firefox Google Play Store app, version 133.0.2 (Build #2016060039), hg-209dcdd9680f+; GV: 133.0.2-20241204213141; AS: 133.0; 2024-12-05T00:59:47.425401693. https://en.m.wikipedia, signed in, text standard, color automatic (machine default dark mode), advanced mode on.

ETA: I restarted my phone a few times, checked to make sure my Android and Firefox were the latest versions, and restarted the application. Didn't resolve the issue.

Thanks for the screen recording that's super helpful! I'm still not able to replicate this, which makes me think that this might relate to instrumentation or some other code that's run for a particular sample of users (e.g. an A/B test)

Can you append ?safemode=1 to the end of the URL and let me know if this issue still persists? I see you have some desktop code loading on mobile from https://en.wikipedia.org/wiki/User:Pingnova/common.js - and I just want to rule that out.

I suspect there's a JavaScript error occurring when you press the search result which is causing the link to not be followed. I just haven't been able to prove that theory yet. Not seeing anything obvious in our error logs.

@Pingnova if you're willing the following code if added to https://en.wikipedia.org/wiki/Special:MyPage/minerva.js will alert any errors occurring in your page view. It would be really helpful for debugging purposes if you could copy that code there and then tell me if you see any alerts during this workflow (you can of course delete it afterwards).

alert('Successfully loaded');
mw.trackSubscribe( 'resourceloader.exception', function ( topic, data ) {
        alert(topic + JSON.stringify(data)); 
} );
// setup the global error handler
mw.trackSubscribe( 'global.error', function ( topic, error ) {
        alert(error + topic);
} );

Hi, I gave that a go but no alert appeared for any issues. I included a recording.

Thanks for your attention to this issue. I primarily edit and read Wikipedia this way, so it has been kind of annoying!

I noticed it is always on the second click. If I dismiss my keyboard and then click back into the search bar and type again, it works. Whatever the issue is, you have to do another action before clicking a result works.

Thanks for trying and ruling out that theory. Sorry I'm not finding a root cause :(

I'm a bit stumped tbh. This code hasn't had any recent modifications and I can't seem to replicate it in browserstack on Samsung Galaxy S22 Ultra so I'd need to find a physical device with the issue to debug it.

There are some existing hacks for iOS device which might be interfering here, and perhaps there are some OS settings I am missing to get replication. It feels like there is an event somewhere which is stopping propagation or preventing default behaviour of the link. Anything in your browser settings that's non-default that might be key? One thing I did notice is that if you have "Reduce animations" set in your Android settings, I do see a large delay on clicking search results. Can you confirm if that setting is enabled or disabled for you?

You can also try clearing your cookies or logging in to a new window incognito to rule out instrumentation being the cause here.

I found the root cause, the performSearch function first resets the search (line 241) and then performs the search only if the search query has changed (line 249).

Firefox triggers the input event when closing the virtual keyboard (despite the comment on line 248, I found that it doesn't trigger on Chrome), this causes the search to reset but since the search query has not changed, a new search is not done and the result links disappear before the tapped link is opened.

The issue seems to be caused by this commit.

Jdlrobson changed the task status from Stalled to In Progress.Jan 3 2025, 1:29 AM
Jdlrobson added a project: Web-Team.

Thanks for the investigation! I still can't replicate this, but your analysis makes sense.

I'll take a look since it seems like I broke this.

Jdlrobson added a subscriber: bwang.

@bwang are you able to replicate this one?

Is this still happening to you @Opencooper and @Pingnova after the latest Firefox release?

The latest .02 patch isn't available for me yet on the Play Store. But the issue is still occurring for me on Firefox 134.0.1. Tapping on results has the effect described, and trying to drag to scroll makes the results get blanked.

This is both in Private mode and when logged in. I tried disabling my only extension, UBlock Origin, but that didn't help either. Changing from portrait to landscape mode had no effect. I also plugged in a wireless mouse via USB OTG, and while I can scroll results with the mouse wheel, clicking on them still doesn't work.

I am sometimes noticing a very long delay when clicking search results, but not the behaviour described here, of the search result not being followed. To be clear, is that the issue being described?

If you wait say 15 seconds after clicking does the page eventually load?

The behavior I'm seeing is exactly as in Pingnova's screen recordings, where, after I click on a search result, the search results disappear, and I am shown the original page I was on. No, the page does not eventually load after waiting.

Okay thanks, we'll keep trying to replicate this then. We have so far been unable to replicate this on several physical devices and on any of the browserstack.com devices with factory default settings so I suspect there is some kind of operating system setting or Firefox setting that is causing this (unless you can also rule that out?).

Really sorry not making any progress on this, but I can't propose a fix unless we can reproduce it and verify the fix. 🤞

I tried to reproduce this on my phone with Android 14, Firefox 134.0.1. Using remote debugging I set a breakpoint on the input event and on resetSearch(). These breakpoints were not hit when clicking a link from the search result list. Also, the breakpoints were not hit when dismissing the on-screen keyboard using the back button.

I suspect this bug is specific to the keyboard being used or some other detail which changes the events Firefox gets from the system. I'm using Gboard which is the default Android keyboard.

I believe my phone uses the Samsung Keyboard from the Galaxy Store, which is the default for my phone. The only customization on it is that I have the high contrast setting on. I included a screenshot of the version and settings. Version at the bottom.

Screenshot_20250121_213315_Samsung Keyboard.jpg (5×1 px, 546 KB)

I additionally reported this to Mozilla via their bug site. https://webcompat.com/issues/147539

Jdlrobson changed the task status from In Progress to Open.Jan 22 2025, 5:02 AM

@Pingnova if you disable predictive text does the problem fix itself?

Jdlrobson changed the task status from Open to In Progress.Jan 22 2025, 5:02 AM

Yes, that does seem to fix the issue.

This fixed it for me using Gboard as well. I had to go into keyboard settings > Text correction, and disable both "Show suggestion strip" and "Spell check".

True, I had not mentioned the fact that I use HeliBoard as my keyboard, I found that the problem doesn't occur if you disable both Auto-correction and Show correction suggestions, apparently the input event on keyboard closing is meant to remove the underline used by auto-correction which does not appear by disabling these settings.

Jdlrobson-WMF changed the task status from In Progress to Stalled.EditedJan 23 2025, 11:48 PM
Jdlrobson-WMF added a project: Upstream.

This appears to be an upstream issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1943502
Awaiting confirmation.

https://bugzilla.mozilla.org/show_bug.cgi?id=1943502 has been reproduced. If we wanted a short term fix here perhaps adding a setTimeout in resetSearch might help for clearing the results, but I've not checked

Jdlrobson-WMF lowered the priority of this task from High to Medium.Jan 31 2025, 7:27 PM

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

[mediawiki/extensions/MobileFrontend@master] Fixes: Selecting search results on mobile website in Firefox does not work

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

Jdlrobson-WMF changed the task status from Stalled to In Progress.Feb 4 2025, 7:15 PM
Jdlrobson-WMF set the point value for this task to 1.
Jdlrobson-WMF moved this task from Q3 to Sprint Backlog on the Web-Team board.

Mozilla got back to me and suggested we use requestAnimationFrame here.
I think this is important to fix as it impacts our A/B test, was caused by the work we took on there in a legacy codebase recently and impacts a lot of our end users.

Test wiki created on Patch demo by Jon (WMF) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/44f45834f6/w/

Test wiki on Patch demo by Jon (WMF) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/44f45834f6/w/

Test wiki created on Patch demo by Jon (WMF) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/a9a8244edd/w/

Working with Mozilla we've got a proposed fixed now that addresses the issue.
https://gerrit.wikimedia.org/r/c/1117240

As noted before:
I think this is important to fix as it impacts our A/B test, and was caused by the work we took on there in a legacy codebase recently and impacts a lot of our end users.

ovasileva raised the priority of this task from Medium to High.Feb 7 2025, 9:57 AM

Change #1117240 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Fixes: Selecting search results on mobile website in Firefox does not work

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

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

[mediawiki/extensions/MobileFrontend@wmf/1.44.0-wmf.15] Fixes: Selecting search results on mobile website in Firefox does not work

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

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

[mediawiki/extensions/MobileFrontend@wmf/1.44.0-wmf.16] Fixes: Selecting search results on mobile website in Firefox does not work

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

Change #1118873 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@wmf/1.44.0-wmf.16] Fixes: Selecting search results on mobile website in Firefox does not work

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

Change #1118841 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@wmf/1.44.0-wmf.15] Fixes: Selecting search results on mobile website in Firefox does not work

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

Mentioned in SAL (#wikimedia-operations) [2025-02-11T22:16:49Z] <jdrewniak@deploy2002> Started scap sync-world: Backport for [[gerrit:1118873|Fixes: Selecting search results on mobile website in Firefox does not work (T381289)]], [[gerrit:1118841|Fixes: Selecting search results on mobile website in Firefox does not work (T381289)]], [[gerrit:1118558|Add search activity id (T383936)]]

Mentioned in SAL (#wikimedia-operations) [2025-02-11T22:19:52Z] <jdrewniak@deploy2002> jdlrobson, jdrewniak: Backport for [[gerrit:1118873|Fixes: Selecting search results on mobile website in Firefox does not work (T381289)]], [[gerrit:1118841|Fixes: Selecting search results on mobile website in Firefox does not work (T381289)]], [[gerrit:1118558|Add search activity id (T383936)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-02-11T22:30:04Z] <jdrewniak@deploy2002> Finished scap sync-world: Backport for [[gerrit:1118873|Fixes: Selecting search results on mobile website in Firefox does not work (T381289)]], [[gerrit:1118841|Fixes: Selecting search results on mobile website in Firefox does not work (T381289)]], [[gerrit:1118558|Add search activity id (T383936)]] (duration: 13m 14s)

Jdlrobson-WMF added a subscriber: Jdrewniak.

I have confirmed the fix in production. Thanks for the deploy @Jdrewniak , thanks to Mozilla for helping work out the best fix here and @Pingnova and @Opencooper for helping us diagnose this very strange bug.

Thanks so much for figuring it out and fixing it. I confirmed just now selecting search results works as expected.

Thanks everyone for all your work in fixing this. I can confirm that selecting search results now works for me on Firefox mobile.

Looking good, resolving!

Test wiki on Patch demo by Jon (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org//wikis/a9a8244edd/w/