2029505 - GBoard gestures (cursor control/swipe-to-delete) fail to work on DuckDuckGo search input in Firefox for Android

Status: VERIFIED FIXED

(GeckoView :: IME, defect)

Description

[Gabe Pérez]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:150.0) Gecko/20100101 Firefox/150.0

Steps to reproduce:

I am experiencing an issue where GBoard's advanced input features (glide typing, spacebar cursor control, and backspace swipe-to-delete) are non-functional specifically within the DuckDuckGo search box.

Steps to reproduce:

1. Open Firefox for Android.
2. Navigate to duckduckgo.com.
3. Tap on the search input field.
4. Try to use GBoard gestures (e.g., sliding the finger over the spacebar to move the cursor or the backspace to swipe-to-delete gesture).

Actual results:

The gestures are ignored. The cursor remains static, and swipe-to-delete does not trigger.

Expected results:

GBoard should handle the input connection correctly, allowing for standard gesture-based text manipulation as it does in other Gecko-based browsers (like Midori) or Chromium-based browsers.

Additional Information:

• Tested with: Enhanced Tracking Protection OFF, uBlock Origin OFF.
• Environment: (Xiaomi) Redmi Note 13 4G; Android 15 (AQ3A.240829.003)/Xiaomi HyperOS 2.0.210.0.VNGMIXM.

Note: The issue seems specific to the interaction between current GeckoView and DDG’s input implementation.

Video: https://www.reddit.com/r/firefox/comments/1sda299/gboard_gestures_not_working_specifically_on/

Comment 1

[Makoto Kato [:m_kato]]

I cannot reproduce this with Pixel 8a + the latest GBoard (us layout). Could you reproduce this on www.google.com too?

Also, if using swipe gesture (don't release finger) on GBoard's keyboard, is all text selected?

Comment 2

[Gabe Pérez]

(In reply to Makoto Kato [:m_kato] from comment #1)

I cannot reproduce this with Pixel 8a + the latest GBoard (us layout). Could you reproduce this on www.google.com too?

Also, if using swipe gesture (don't release finger) on GBoard's keyboard, is all text selected?

Hi. No, it only happens on DuckDuckGo.

​On the DuckDuckGo front page, keyboard gestures work fine. However, when trying to use the search box from the results page, the gestures don't work, except for the first few seconds before the page finishes loading.

​The same behavior is present in other keyboards, such as Microsoft SwiftKey.

Comment 3

[Makoto Kato [:m_kato]]

Ah, this issue occurs on search result page only, not top page. (ex. https://duckduckgo.com/?ia=web&origin=funnel_home_google&t=hp&q=sample)

According to mozregression, regression range is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e835d0f9fea4b05436e5f3be55c9c4e31a82f377&tochange=a810895a0020d2d6be3ccf63452b8808a0d020a4

Comment 5

[BugBot [:suhaib / :marco]]

:emilio, since you are the author of the regressor, bug 2016280, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[Gabe Pérez]

(In reply to Makoto Kato [:m_kato] from comment #3)

Ah, this issue occurs on search result page only, not top page. (ex. https://duckduckgo.com/?ia=web&origin=funnel_home_google&t=hp&q=sample)

According to mozregression, regression range is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e835d0f9fea4b05436e5f3be55c9c4e31a82f377&tochange=a810895a0020d2d6be3ccf63452b8808a0d020a4

Hi. Yes, the issue occurs in search results. Additionally, when using suggestions, autocompleted words get piled up, forcing you to select the entire element to edit it manually instead of using keyboard gestures.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Makoto do you know how are these actions communicated to Gecko?

Comment 8

[Makoto Kato [:m_kato]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #7)

Makoto do you know how are these actions communicated to Gecko?

C++ side is called as IME_REPLACE_TEXT: aStart=0, aEnd=2, aText="", mIMERanges=0, mIMEKeyEvents=0 in https://searchfox.org/firefox-main/rev/dab03896ede1413be148884e054b311767bcf1a0/widget/android/GeckoEditableSupport.cpp#876-877. GeckoView sets the selection on content process by https://searchfox.org/firefox-main/rev/dab03896ede1413be148884e054b311767bcf1a0/widget/android/GeckoEditableSupport.cpp#943-948, but selection isn't updated.

Comment 9

[Makoto Kato [:m_kato]]

Also, finally mSelection->SetBaseAndExtentInLimiter is called by ContentEventHandler::OnSelectionEvent.

https://searchfox.org/firefox-main/rev/dab03896ede1413be148884e054b311767bcf1a0/dom/base/Selection.cpp#4277 is false. So I guess that root cause is ConvertFlatTextOffsetToUnsafeDOMRange or SetBaseAndExtentInLimiter (for shadow DOM).

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't understand yet, do you mean that the range passed to SetBaseAndExtentInLimiter is bad? If so, could you comment which nodes and offsets are passed to the method?

(Currently, TextEditor works only with a Text. Therefore, we could make ContentEventHandler simpler for <input> and <textarea>. If mRootElement is the anonymous <div>.)

MOZ_LOG=SelectionAPI:3,sync might help you.

Comment 11

[Makoto Kato [:m_kato]]

I don't understand why this issue occurs on Duck Duck Go's search result page yet. It uses input element (<input id="search_form_input" ...>).

Widget side uses WidgetSelectionEvent to set selection, then ContentEventHandler::OnSelectionEvent to handle this. It uses SetBaseAndExtentInLimiter, but since HasSameRootOrSameComposedDoc is false, SetBaseAndExtentInLimiter returns without error.

Comment 12

[Makoto Kato [:m_kato]]

GetSelectionAndRoot might return old selection? Editor might be re-created by reflow or something?

Comment 13

[Emilio Cobos Álvarez [:emilio]]

This smells a bit like bug 2014481 fwiw.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Indeed the example in that bug also reproduces this issue.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2029505 - Don't cache selection in IMEContentObserver. r=m_kato!

The selection controller might be recreated without editor recreation
itself. This could already realistically happen before bug 2016280 as
far as I can tell.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

So the main difference is that before bug 2016280 the whole editor got torn down and up again (the anonymous content got recreated) and now it doesn't. I have a patch that fixes it, but I don't know what the best way to test this is. Makoto, could you point me at some tests that I could crib from? Something like the test-case from bug 2014481 but with these IME actions should work afaict.

Comment 17

[Emilio Cobos Álvarez [:emilio]]

Ok, I found nsIDOMWindowUtils.sendSelectionSetEvent and came up with a test-case that fails before my patch and works with it.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1c763198a67e
https://hg.mozilla.org/integration/autoland/rev/2b5482d3727c
Don't cache selection in IMEContentObserver. r=m_kato,masayuki

Comment 19

[alvinhochun]

Can this be uplifted to Firefox 150?

Comment 20

[rperta]

https://hg.mozilla.org/mozilla-central/rev/2b5482d3727c

Comment 21

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: comment 0
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: targetted fix.
• String changes made/needed?: none
• Is Android affected?: yes

Comment 22

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2029505 - Don't cache selection in IMEContentObserver.

The selection controller might be recreated without editor recreation
itself. This could already realistically happen before bug 2016280 as
far as I can tell.

Original Revision: https://phabricator.services.mozilla.com/D295508

Comment 23

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: comment 0
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: targetted fix.
• String changes made/needed?: none
• Is Android affected?: yes

Comment 24

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2029505 - Don't cache selection in IMEContentObserver.

The selection controller might be recreated without editor recreation
itself. This could already realistically happen before bug 2016280 as
far as I can tell.

Original Revision: https://phabricator.services.mozilla.com/D295508

Comment 25

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2016280

Comment 26

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/405e434dccc6
https://hg.mozilla.org/releases/mozilla-beta/rev/4540211ce843

Comment 27

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/8c1b0fcb5ac9
https://hg.mozilla.org/releases/mozilla-release/rev/bffcc77f051f

Comment 28

[Lorand Janos]

Verified as fixed on the latest Nightly 152.0a1 and on the latest Beta (151.0b2) builds.

The GBoard handles the input connection correctly, allowing for standard gesture-based text manipulation.

Devices used:

• Samsung Galaxy S25 Ultra (Android 16);
• Xiaomi Mi11 Lite (Android 11).

Comment 32

[Denys [:denyshon]]

Hey Donal, could you please clarify why this bug is set as fixed for release (v150), but bug 2023328 is not? If it's indeed fixed in release, which version will (doed) include the fix?

Comment 33

[Donal Meehan [:dmeehan]]

Fenix 150.0.1 released today and includes the fix tracked here

Comment 34

[Denys [:denyshon]]

Thank you!