1134493 - Keyboard closes after typing one character when lockscreen is disabled

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[Botond Ballo [:botond]]

STR:
  1. Open the Browser app.
  2. Tap the address bar. The keyboard opens.
  3. Tap a key.

Expected results:
  A character is entered into the address bar.
  The keyboard remains open.

Actual results:
  A character is entered into the address bar.
  The keyboard closes.

The behaviour becomes even worse after this. When you re-open the keyboard and tap a key again, a character isn't even entered into the address bar - the keyboard just closes.

I'm running with Gecko and Gaia pulled today. In particular, I verified that I have the patch from 1129344 applied, but I still see the problem. 

It basically makes the phone unusable...

Comment 1

[Botond Ballo [:botond]]

This issue has largely gone away after a full rebuild + reflash with today's trunk.

Comment 2

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #1)
> This issue has largely gone away after a full rebuild + reflash with today's
> trunk.

*Sigh*. No it hasn't - it's just intermittent. Seems to be particularly bad when the key pressed in <backspace>.

Comment 4

[Kevin Grandon :kgrandon]

From bug 1135938 comment 2

Etienne, Kats - I've confirmed that backing out the gaia patch in bug 1130011 makes this go away. It seems that we're not *actually* catching any events in those listeners though, so I assume we're going through some different APZ patch and triggering touch/focus events when we don't want them.

Comment 5

[Kevin Grandon :kgrandon]

It looks like bug 1130011 is not yet in 2.2, so this is only happening in 3.0.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Hm, interesting. If you want to back out bug 1130011 for now I'm ok with that. I can take a look to see what's going on although it probably won't be until later this week. I'll have to repro this problem first since I haven't been seeing it on my Flame lately. Leaving ni on me for now.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I can repro this if I disable the lockscreen, which effectively removes the touch listeners on the system window. (If bug 1130016 gets fixed then this issue will be reproducible even without disabling the lockscreen). Looking into it.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

I think this is happening because the code at http://mxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp?rev=34a3bc7200c1#629 forces the hit region of the entire keyboard process to empty. So if there's stuff in the rocketbar search results behind the keyboard that will get hit instead, and dismiss the keyboard. When you first bring up the rocketbar the results are generally empty so the hit goes to the system process which sends it to the keyboard process via main-thread dispatch and so it works that time. Having listeners on the root window in the system process also helps because it forces APZ to wait for the response... I think.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Technically this is a regression from bug 1131840, and it was bug 1130011 that exposed it. Marking 2.2 as affected since bug 1131840 was uplifted there.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: Account for mozpasspointerevents when setting force-ehr flag

Comment 11

[Kartikaya Gupta (email:[e-mail])]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0cd728a477b3

Comment 13

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> I can repro this if I disable the lockscreen, which effectively removes the
> touch listeners on the system window.

By the way, this explains why the problem went away for me after a full flash (comment 1), which resets settings to defaults (which for the lockscreen is enabled), and then came back shortly after (comment 2) when I would have disabled the lockscreen again.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/integration/mozilla-inbound/rev/64f22e3076ea

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/64f22e3076ea

Comment 16

[Hermes Cheng (inactive after July 27, 2015)]

Could you please also uplift to v2.2? Thanks!

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8568738 [details] [diff] [review]
Account for mozpasspointerevents when setting force-ehr flag

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Caused by 1131840 but exposed by 1130011.
User impact if declined: If the lockscreen is disabled, then it becomes very hard to type in the keyboard as it will dismiss itself frequently (almost always)
Testing completed: locally
Risk to taking this patch (and alternatives if risky): low risk patch; the bug is an oversight in my patches for bug 1131840 where I forgot to check the mozpasspointerevents attribute in one place.
String or UUID changes made by this patch: none

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7ee9dca6b685

Comment 19

[Hermes Cheng (inactive after July 27, 2015)]

verify for 2.2. Add 'verifyme' for master branch.

*v2.2 env info:
Build ID               20150302162504
Gaia Revision          062d395273e70b8688a91b5a2b34c0cc7afc679f
Gaia Date              2015-03-02 22:12:55
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5a7cb3b9f78e
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150302.195105
Firmware Date          Mon Mar  2 19:51:14 EST 2015
Bootloader             L1TC000118D0

Comment 20

[Shally Li（leave from Mozilla）]

This bug has been successfully verified on latest Flame v3.0.
See attachment: verified_v3.0.mp4
Reproduce rate: 0/5

STR:
1.Disable screenlock.
2.Open Browser app.
3.Tap the address bar. 
**The keyboard opens.
4.Tap a key on keyboard.
**The character is entered into the address bar.And the keyboard remains open as expected.

Flame 3.0 build:
Build ID               20150303010233
Gaia Revision          c8ed1085a67490a1ecd7f275e5de9487e1b93b1d
Gaia Date              2015-03-02 20:14:21
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/0b3c520002ad
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150303.044015
Firmware Date          Tue Mar  3 04:40:27 EST 2015
Bootloader             L1TC000118D0
-------------------------------------------------------------------------------
Leaving "verifyme" for firefox39.

Comment 21

[Shally Li（leave from Mozilla）]

Attachment: verified_v3.0.MP4

Comment 22

[Kartikaya Gupta (email:[e-mail])]

This bug doesn't affect desktop, so changing status to verified.