Virtual Keyboard is not dismissed if a tap is performed outside the focused input field

VERIFIED FIXED

Status

()

Firefox for Android
General
P1
normal
VERIFIED FIXED
6 years ago
10 months ago

People

(Reporter: xti, Assigned: wesj)

Tracking

unspecified
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox11 fixed, fennec11+)

Details

(Whiteboard: [testday-20111111], [VKB])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Mozilla/5.0 (Android;Linux armv7l;rv:10.0a1)Gecko/20111111
Firefox/10.0a1 Fennec/10.0a1
Devices: Motorola Droid 2
OS: Android 2.3.3

Steps to reproduce:
1. Open Fennec App
2. Browse to www.google.com
3. Tap on search field
4. Perform a tap anywhere else except the search field

Expected result:
After step 3, the VKb is triggered.
After step 4, the VKb is dismissed.

Actual result:
After step 4, the VKb is still displayed on screen. It will be dismissed only if the device back button is tapped.

Comment 1

6 years ago
This behavior closes properly on Fennec XUL and Android Stock browser.  Since this seems like a regression to Fennec XUL, we should fix this.

Updated

6 years ago
Assignee: nobody → wjohnston

Updated

6 years ago
Depends on: 698154

Updated

6 years ago
Whiteboard: [testday-20111111] → [testday-20111111], [VKB]
Regression caused by the new pan/zoom layers architecture. It worked before.

Updated

6 years ago
Priority: -- → P1
As I mentioned in my comment for bug 701947, that issue and this one are caused by the new check in the BrowserEventHandler.handleEvent() function: http://hg.mozilla.org/projects/birch/file/04b6e59f4e82/mobile/android/chrome/content/browser.js#l1300
It calls _elementReceivesInput() function, which returns false for the area outside of the edit boxes, so the "mousedown" event is not handled properly.
Created attachment 576067 [details] [diff] [review]
Workaround

This patch removes the recently introduced check for an element receiving input, and the call to aEvent.preventDefault() if it isn't. This fixes the current regression with VKB not being dismissed, as well as the bug 701947. Apparently it should break the conditions which that code was added for, but I don't quite understand what kind of an unwanted selection that call to aEvent.preventDefault() originally stopped.
As this bug is quite important, we could apply the workaround patch, and fix the selection bug (if any) separately doing it some alternative way which does not break the working stuff.
Comment on attachment 576067 [details] [diff] [review]
Workaround

This patch will fix the "click doesn't remove focus" issues, but will cause the "text is selected while panning" issues to return.

I think XUL Fennec made this work because the "mousedown" was queued and redispatched after we were sure a pan did not happen.
(In reply to Mark Finkle (:mfinkle) from comment #5)

> This patch will fix the "click doesn't remove focus" issues, but will cause
> the "text is selected while panning" issues to return.

I don't see that text selection bug with the new panning implementation. Now the panning continues even when there is nowhere to pan, beyond the boundaries (then springs back on release), so the selection is not happening as it was before.
(In reply to Alex Pakhotin (:alexp) from comment #6)
> (In reply to Mark Finkle (:mfinkle) from comment #5)
> 
> > This patch will fix the "click doesn't remove focus" issues, but will cause
> > the "text is selected while panning" issues to return.
> 
> I don't see that text selection bug with the new panning implementation. Now
> the panning continues even when there is nowhere to pan, beyond the
> boundaries (then springs back on release), so the selection is not happening
> as it was before.

Really? I have to try this for myself. It would be really great to kill the code here and in bug 701947.
(In reply to Mark Finkle (:mfinkle) from comment #7)
> (In reply to Alex Pakhotin (:alexp) from comment #6)
> > (In reply to Mark Finkle (:mfinkle) from comment #5)
> > 
> > > This patch will fix the "click doesn't remove focus" issues, but will cause
> > > the "text is selected while panning" issues to return.
> > 
> > I don't see that text selection bug with the new panning implementation. Now
> > the panning continues even when there is nowhere to pan, beyond the
> > boundaries (then springs back on release), so the selection is not happening
> > as it was before.
> 
> Really? I have to try this for myself. It would be really great to kill the
> code here and in bug 701947.

I tried this patch and it still causes text selections. I opened planet.mozilla.org and panned around in a circle over some text paragraph. The text became selected at various times as I panned around.
Attachment #576067 - Flags: review-
(In reply to Mark Finkle (:mfinkle) from comment #8)
> I tried this patch and it still causes text selections. I opened
> planet.mozilla.org and panned around in a circle over some text paragraph.
> The text became selected at various times as I panned around.

Finally I've seen what it's all about. Wasn't easy to reproduce, but sometimes it does happen.
OK then. Hopefully Wes has got some real fix.
(Assignee)

Comment 10

6 years ago
fixed in bug 704579
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 11

6 years ago
Retested bug with:
Mozilla/5.0 (Android;Linux armv7l;rv:11.0a1)Gecko/20111208
Firefox/11.0a1 Fennec/11.0a1
Device: HTC Desire Z(Android 2.3)

VKb is dismissed when a tap is performed outside the focused input field.

Verifying bug.
Status: RESOLVED → VERIFIED
tracking-fennec: --- → 11+
status-firefox11: --- → fixed
You need to log in before you can comment on or make changes to this bug.