Virtual keyboard continually dismisses on first match and match advancing in Find in Page

VERIFIED FIXED in Firefox 15

Status

()

Firefox for Android
General
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: aaronmt, Assigned: mbrubeck)

Tracking

({regression})

15 Branch
Firefox 16
ARM
Android
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15 verified, firefox16 verified, firefox17 verified)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Steps to Reproduce:

i) http://en.wikipedia.org/wiki/Mozilla
ii) Query for 'Mozilla'
iii) Hit the down arrow, and see the keyboard dismiss


Tested via 

Samsung Galaxy Nexus (Android 4.0.4)
20120531040223
http://hg.mozilla.org/integration/mozilla-inbound/rev/ff2ad97929e8
(Reporter)

Comment 1

6 years ago
It seems to also dismiss on first match when searching in landscape and in portrait.
Summary: Virtual continually keyboard dismisses on match advancing in Find in Page → Virtual keyboard continually dismisses on match advancing in Find in Page

Comment 2

6 years ago
Is the Find bar still visible? Are we sure this isn't expected behavior?
(Reporter)

Comment 3

6 years ago
The finder bar is still visible but this prevents one from completing a query for an entire string one wishes to enter. What's happening is that one first match for a partial string, the keyboard dismisses.

STR again:

i) Visit http://neowin.net with the intent to enter 'Windows'
ii) Trigger "Find in Page", start typing "win" or "wind", match is met and keyboard is dismissed without the ability to enter 'Windows'.
(Reporter)

Updated

6 years ago
Summary: Virtual keyboard continually dismisses on match advancing in Find in Page → Virtual keyboard continually dismisses on first match and match advancing in Find in Page
(Assignee)

Comment 4

6 years ago
Possible related, the keyboard does not automatically appear when the Find bar is first activated, although from the code it looks like it is supposed to.
Assignee: nobody → mbrubeck
(Assignee)

Comment 5

6 years ago
When a match is highlighted, we receive a NOTIFY_IME_RESETINPUTSTATE event from Gecko here:
http://hg.mozilla.org/mozilla-central/file/e96e0eaa6d85/mobile/android/base/GeckoInputConnection.java#l931

Then this code steals focus from the Find bar by focusing the content view instead:
http://hg.mozilla.org/mozilla-central/file/e96e0eaa6d85/mobile/android/base/GeckoInputConnection.java#l1043
(Assignee)

Comment 6

6 years ago
This is a regression from bug 750734.
Blocks: 750734
Keywords: regression
(Assignee)

Comment 7

6 years ago
Created attachment 630766 [details] [diff] [review]
patch

This fixes the problem from this bug (comment 0) without regressing 750734.  Instead of stealing focus every time the IME state changes, this just makes sure the view gets focused when it's been tapped.

Review question: Does the new requestFocus() call need to be posted to the main thread handler, like the old one was?  I'm not too clear about what happens on which thread in this code.
Attachment #630766 - Flags: review?(cpeterson)
(Assignee)

Updated

6 years ago
Blocks: 762309
(Assignee)

Comment 8

6 years ago
(In reply to Matt Brubeck (:mbrubeck) from comment #4)
> Possible related, the keyboard does not automatically appear when the Find
> bar is first activated.

This turned out to be unrelated.  I filed bug 762309 for this issue.
Status: NEW → ASSIGNED
Version: unspecified → Firefox 15
Comment on attachment 630766 [details] [diff] [review]
patch

Review of attachment 630766 [details] [diff] [review]:
-----------------------------------------------------------------

r+

Sorry for the delay.

> Review question: Does the new requestFocus() call need to be posted to the main thread handler, like the old one was?  I'm not too clear about what happens on which thread in this code.

I think this is safe. I'm not familiar with the LayerView code, but LayerView.onTouchEvent() is presumably running on the UI thread because it calls mTouchEventHandler.handleEvent() and TouchEventHandler.java has big warnings that it must run on the UI thread. GeckoApp and GeckoAppShell call TouchEventHandler from a Runnable posted to mMainHandler, so I think it is safe to assume your code is safe.

We should probably add some debug code to TouchEventHandler to assert it is called on the correct thread.
Attachment #630766 - Flags: review?(cpeterson) → review+
(Assignee)

Comment 11

6 years ago
Comment on attachment 630766 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 695172

User impact if declined: Find In Page is unusable because the keyboard disappears while you are typing.

Testing completed (on m-c, etc.): Landed on inbound 6/8

Risk to taking this patch (and alternatives if risky): Low-risk android-only patch.

String or UUID changes made by this patch: None.
Attachment #630766 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/0a468957ace8
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite-
Resolution: --- → FIXED

Updated

6 years ago
Attachment #630766 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 13

6 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/275cf57ac110
status-firefox15: affected → fixed
tracking-firefox15: ? → ---
(Assignee)

Comment 14

6 years ago
We could use some FindInPageBar tests.
Flags: in-testsuite- → in-testsuite?
Depends on: 771989
The issue is still reproducible on both Nightly 16.0a1 and Aurora 15.0a2 2012-07-08. A follow-up bug has been opened for the issue - please see Bug 771989. Leaving the issue closed but unverified until Bug 771989 is fixed.
(Reporter)

Updated

6 years ago
Status: RESOLVED → VERIFIED
status-firefox15: fixed → verified
status-firefox16: --- → verified
status-firefox17: --- → verified
(Assignee)

Updated

5 years ago
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.