1940915 - m.wikipedia.org - Not getting redirected after choosing a search suggestion, with certain software keyboards on Android

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Calin Tanase]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile [phone]

Steps to reproduce:

1. Go to https://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal
2. Tap on the search icon.
3. Type something in the search bar.
4. Tap on any of the suggested results.
5. Observe the behavior.

Expected Behavior:
Redirected to that page.

Actual Behavior:
Does not get redirected, suggested results menu closes.

Notes:

• Personally I was not able to reproduce but we have received multiple reports regarding this issue
• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/145467

Comment 1

[heinrich5991]

I can reproduce on a clean profile on Firefox Nightly downloaded from the Play Store, on https://en.m.wikipedia.org/wiki/Main_Page, searching for "foobar" and clicking the first result.

136.0a1 (Build #2016066847), hg-6da2f152d57b+
GV: 136.0a1-20250109093225
AS: 136.20250108050329

OS: Android 14, LineageOS 21-20241026-microG

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 3

[Dennis Schubert [:denschub]]

This works for me now, but given the number of duplicates, we should look more into this.

Comment 4

[heinrich5991]

I can still reproduce on a clean profile on Firefox Nightly downloaded just now from the Play Store, following my above steps.

136.0a1 (Build #2016067423), hg-abc92a419107+
GV: 136.0a1-20250112090142
AS: 136.20250110050330

This problem has existed for me for a couple of weeks at least, on stable. I don't know how long it has existed, maybe even longer.

Comment 5

[Daniel Holbert [:dholbert]]

FWIW, so far I'm not able to reproduce (I tested with fr. and en. wikipedia links above, in current release as well as nightly, on my Pixel 8 running Android 15).

I'm very curious what the relevant variable(s) might be that make this reproducible... But for now I think we need some clues.

@heinrich5991 or other folks: two requests to help give clues about what might be going on:
(1) would you mind recording a screencast of the bug?
(2) would you mind recording and sharing a Performance Profile? (You may want to do this with no other tabs open in the Firefox instance that you're profiling, since a performance profile may include information about background tabs.) To capture a performance profile:

• Activate the debug menu ( https://firefox-source-docs.mozilla.org/mobile/android/fenix/Secret-settings-debug-menu-instructions.html )
• Open the 3-dot menu and choose "Settings" (might show up as a cog icon in Nightly, depending on A/B testing group) and then "Start Profiler" and tap through the dialog.
• Reproduce the bug.
• Go back to where you found "Start Profiler" and tap "Stop Profiler"
• Share the provided URL here.

Thanks!

Comment 6

[heinrich5991]

Attachment: en.wikipedia.org-foobar-pixel4a.mp4

I recorded a screencast of me doing the "foobar" search on the english wikipedia. I couldn't find a way to easily record taps, but in the end, I tap on the first search result.

Again on the newest nightly, with all app data removed beforehand.

136.0a1 (Build #2016067631), hg-000fac19cadd+
GV: 136.0a1-20250113093612
AS: 136.20250110050330

https://profiler.firefox.com/public/qq10n4jxfyms8kcxwttxqwvp35g87661tr8dq28

Comment 7

[Daniel Holbert [:dholbert]]

Thanks! One thing I'm noticing in your screencast as well as in your profile's "screenshots" track (which is like a micro-screencast) -- it looks like the images aren't loading on the left hand side of the search results (after you type "foobar").

Do those images eventually load if you wait a bit longer after typing "foobar" and before you tap? And do things work out differently if you tap after they've loaded?

In any case, here's a profile of things-working-just-fine for me (no bug):
https://profiler.firefox.com/public/zq3yk946yhfsp136axsww6t34k61fh47qahgb58

In my case the images did load just before I tapped, though I don't know if that matters. (I tried again and managed to tap before they loaded I think, but I still got good results.)

My profile shows that I'm very briefly getting the same outcome as you (results menu disappears and I see the original wikipedia page) but then I'm immediately navigated to the correct page.

Comment 8

[Daniel Holbert [:dholbert]]

Narrowing in a bit in case it's useful for comparison to find clues about anything different + potentially interesting....

• Here's heinrich's "bad" profile zoomed into the moment of truth (tapping the search result + failure-to-navigate):
  https://share.firefox.dev/3DYO7qY

• vs. here's my "good" profile zoomed to the moment of truth (when I tap the search result + successfully navigating):
  https://share.firefox.dev/3Cl1ZuV

Comment 9

[heinrich5991]

Do those images eventually load if you wait a bit longer after typing "foobar" and before you tap? And do things work out differently if you tap after they've loaded?

Yes, they eventually load. Waiting until they are loaded does not change the outcome for me.

Comment 10

[Holger Benl [:hbenl]]

I was able to reproduce this in Nightly but not in Stable. Furthermore I noticed that the search result list disappears in Nightly when I close the on-screen keyboard, so I dug into that. I found that Nightly sends an extra input event (with isComposing: false and inputType: "insertCompositionText" properties) when closing the keyboard that Stable doesn't send and the event handler hides the search results (it looks like it's trying to kick off another search but then fails somehow).
I think that this is the root cause of the issue, especially since I found this comment saying that the issue does not reproduce when the last character in the search field is a space and I've verified that in that case the extra event is also not sent.
--> sending to the DOM team for further diagnosis

Comment 11

[heinrich5991]

Interesting. I can still reproduce that behavior in Fennec 134.0.0 and in Firefox Nightly.

In stable: I can confirm that adding a space after the search term and then clicking the result works correctly. Adding a space and then removing it again also works. What doesn't work is adding a letter (say "a") and removing it again and then clicking the result, that results in the bug described here.

Comment 12

[Sean Feng [:sefeng211]]

The "input" event mentioned by Holger indeed suspicious. I also see an extra input event dispatched in heinrich5991 profile but not in Daniel's profile.

This looks like a platform bug to me, though we still need a better way for reproducing.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Holger Benl from comment #10)

I was able to reproduce this in Nightly but not in Stable. [...] I found that Nightly sends an extra input event [...] when closing the keyboard that Stable doesn't send and the event handler hides the search results (it looks like it's trying to kick off another search but then fails somehow).
I think that this is the root cause of the issue

I still haven't been able to reproduce (even with the observation about presence/absence of a trailing space being significant), but as sefeng notes, this^ seems like an important observation. (This presumably isn't a regression in current Nightly, since comment 0 mentions this having been observed on older versions as well, in our older webcompat.com reports -- maybe the extra input event is dependent on some preference that has a Nightly-channel-specific experimental default value, that was added several months back, or something.)

Given that there's a nighlty-vs-stable difference, it's likely we can figure out where this was introduced using mozregression. (I'd do that, but as noted I can't repro.) Holger, have you used mozregression on Firefox-for-Android in the past, & would you be willing to give it a try here? I'm happy to hop on a zoom call at some point, to help out, if you're willing.

(One minor Android-specific footgun to be aware of -- as part of installing Nightly builds, mozregression will replace your existing Nightly installation and clobber Nightly's profile-data as a result of that, due to how Android manages app data. So you may want to either get comfortable with losing your Nightly data :) or try mozregression on a test device, if you've got one that reproduces the bug.)

Comment 14

[Holger Benl [:hbenl]]

I tried using mozregression -n fenix --arch arm64-v8a --launch <release> with the releases 135, 130, 120, 110, 100, 97 (97 was the oldest release that mozregression could find) and in all cases I could reproduce. I also tried with fresh installs of Stable and Beta and in both cases I could not reproduce. This was on a Sony Xperia XZ1 Compact with Android 9.
I then switched to another device (Lenovo Smart Tab M8 with Android 10) and on that device I could not reproduce in either Stable (with an old profile that I didn't want to lose) or a fresh install of Nightly.
This is quite mysterious. Perhaps the DOM team has an idea what could possibly be the factor determining if this extra input event is sent or not.

Comment 15

[Daniel Holbert [:dholbert]]

It looks like we've now got bug 1943502 with a reduced testcase, and with a mention of "predictive text" which is an Android keyboard platform feature that seems to be involved here.

Let's consider this to be dependent-on that bug as a platform bug.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #15)

It looks like we've now got bug 1943502 with a reduced testcase, and with a mention of "predictive text" which is an Android keyboard platform feature that seems to be involved here.

Turns out that this "Predictive Text" option was is a setting in the Samsung software-keyboard software, which isn't broadly available for installation on non-Samsung devices. But Microsoft SwiftKey ( https://play.google.com/store/apps/details?id=com.touchtype.swiftkey ) seems to trigger the same behavior, and I confirmed that I can reproduce this bug using that keyboard.

Comment 17

[Daniel Holbert [:dholbert]]

Update, per bug 1943502 comment 33: we've found an approach that avoids this issue in Wikipedia, and Wikipedia folks are working on getting that deployed. And the underlying platform difference between Firefox and Chrome here is a Chromium bug ( https://issues.chromium.org/issues/41439787 ).

--> removing webcompat:platform-bug, and adding webcompat:contact-complete

Comment 18

[Daniel Holbert [:dholbert]]

(also removing fr. from the bug title, since this affects any/all wikipedia localizations, not just the fr. one.)

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #17)

we've found an approach that avoids this issue in Wikipedia, and Wikipedia folks are working on getting that deployed.

The fix was deployed by Wikipedia folks today, and I confirmed that I can no longer reproduce this bug.

I tested on my own Pixel 6a with the "Swiftkey" keyboard referenced in comment 16, and also on BrowserStack using a Samsung Galaxy S22 Ultra (which has its own Samsung predictive-text keyboard).

In both cases I confirmed that I can still rerproduce the bug in a "patchdemo" staged version of Wikipedia with an incomplete/abandoned fix ( https://patchdemo.wmcloud.org/wikis/20385674af/wiki/New_York ), and I confirmed I cannot reproduce on the live Wikipedia site.

--> I think we can call this FIXED. Hooray! Folks who were hitting this, please let us know if you happen to still be able to reproduce (either here or in a new bug in the hopefully-unlikely event that you can still repro).