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

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Cristian Nicolae (:xti)]

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

[Tony Chung [:tchung]]

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

Comment 2

[Alex Pakhotin (:alexp)]

Regression caused by the new pan/zoom layers architecture. It worked before.

Comment 3

[Alex Pakhotin (:alexp)]

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.

Comment 4

[Alex Pakhotin (:alexp)]

Attachment: 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 5

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 6

[Alex Pakhotin (:alexp)]

(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.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(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.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(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.

Comment 9

[Alex Pakhotin (:alexp)]

(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.

Comment 10

[Wesley Johnston (:wesj)]

fixed in bug 704579

Comment 11

[Carla Nadastean]

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.