1064648 - Hitting power button while the keyboard is invoked shows 1/2 of Homescreen

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Marcia Knous [:marcia]]

Attachment: 2014-09-08-18-03-47.png

[Blocking Requested - why for this release]: This bug doesn't happen in 2.0, and is a very visible UI regression.

Flame, while running:

Gaia   a8e4d26555e5713ec6c72270cfd0cfabc096a0d3
SourceStamp 746f24f9d21d
BuildID 20140908000204
Version 34.0a2
v. 123

STR:

Make sure screen lock is enabled

1. Settings -> Screen Lock -> Passcode Lock
2. Hit the Power button

Observe the attached screenshot - since keyboard has been invoked it is drawing the keyboard on the homescreen.

This bug doesn't occur in the latest 2.0 build, but does occur on the latest Master build.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Flagging status-b2g according to comment 0.

Triage: +'ing for UI breakage.

Tentatively assign to Greg until regressed bug is found.

Comment 2

[Adam Alldredge [:AdamA][Inactive]]

B2G-Inbound Regression Window:

Last working:
Device: Flame 2.1
BuildID: 20140828110248
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: 1138e8f07c48
Version: 34.0a1 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken:
Device: Flame 2.1
BuildID: 20140828111249
Gaia: e6e7a3decde81860b0ce1f38adc887612033aea3
Gecko: 6754f7b6d327
Version: 34.0a1 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Last working Gaia First Broken Gecko: Issue does NOT reproduce
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: 6754f7b6d327

First Broken Gaia Last working Gecko: Issue DOES reproduce
Gaia: e6e7a3decde81860b0ce1f38adc887612033aea3
Gecko: 1138e8f07c48

Pushlog:
https://github.com/mozilla-b2g/gaia/compare/007f3c50cf69f044628a23c2376c6d88aa45f617...e6e7a3decde81860b0ce1f38adc887612033aea3

Caused by Bug 1054126

Comment 3

[Joshua Mitchell (Inactive)]

Caused by Bug 1054126 ? Can you take a look George

Comment 4

[(Inactive after June) George Duan [:gduan] [:喬智]]

Hi Marcia,
I tried to repro it on 20140909040219 (https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-eng/2014/09/2014-09-09-04-02-19/) master build and video is as below.

https://www.dropbox.com/s/qh50hhtvtqwkqe6/VID_20140911_095849.mp4?dl=0

It seems that I didn't repro what you mentioned in comment 0. Have I missed any step?

Comment 5

[Marcia Knous [:marcia]]

(In reply to George Duan [:gduan] [:喬智] from comment #4)
> Hi Marcia,
> I tried to repro it on 20140909040219
> (https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-
> central-flame-eng/2014/09/2014-09-09-04-02-19/) master build and video is as
> below.
> 
> https://www.dropbox.com/s/qh50hhtvtqwkqe6/VID_20140911_095849.mp4?dl=0
> 
> It seems that I didn't repro what you mentioned in comment 0. Have I missed
> any step?

George: I retested this on Flame today using the latest 2.1 build, and I can still reproduce it with those steps, at least the first time I press the power button. It seems that the second time I do with the keyboard open I don't see the issue. I am flashing my builds using the TPE flashing tool.

Gaia   d61264cd0c1f797b6be11e33524d8d52983c87e4
SourceStamp 1d44dfce2e5b
BuildID 20140911000225
Version 34.0a2
base: v123

I think in the video you showed, you pressed the "Home" button. I am pressing the Power button at the top of the device to reproduce the issue.

STR:
1. Settings -> Screen Lock -> Passcode Lock
2. Press the Power button at the top of the device to lock the screen.
3. Observe the screenshot I added in the attachment.

Comment 6

[Adam Alldredge [:AdamA][Inactive]]

When I was obtaining the regression window for this I noticed that if you left the phone on a black screen for too long before viewing the lock screen the keyboard would have time to close. This would cause the bug to not be present. That may be a cause of the bug not reproducing in some cases.

Comment 7

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

Hi Alive,
could you take a look of this patch?
The root cause is, bug 1054126 resize lockscreen window if switching from app with fullscreen_layout.

When user hit the power button, the keyboard is hidden after calling navigator.mozInputMethod.removeFocus() in keyboard_manager by lockscreen-appopened event. So, layout_manager cannot get keyboardhide event earlier than lockscreen.resize.

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8488134 [details] [review]
PR to master

Sorry, this will make lockscreenWindow/secureWindow/attentionWindow never got resized when lockscreen is on.

I think the proper way should be let KeyboardManager listen to lockscreen-request-unlock and hide the keyboard immediately.

Comment 9

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8488134 [details] [review]
PR to master

I think it should be lockscreen-request-lock instead of unlock.
Could you check it again? Thanks.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to George Duan [:gduan] [:喬智] from comment #9)
> Comment on attachment 8488134 [details] [review]
> PR to master
> 
> I think it should be lockscreen-request-lock instead of unlock.
> Could you check it again? Thanks.

lockscreen.js is already dispatching |lockscreen-request-lock|, what's the need to do it again?

Comment 11

[Greg Weng [:snowmantw][:gweng][:λ]]

In lockscreen.js there is no need to fire |lockscreen-request-lock|, since when lockscreen.js can do something, it means LockScreenWindow has been activated (opened), and this status in LockScreenWindowManager means now it's locked. The event is mainly for locking programmingly. Unless George found a bug.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #10)
> (In reply to George Duan [:gduan] [:喬智] from comment #9)
> > Comment on attachment 8488134 [details] [review]
> > PR to master
> > 
> > I think it should be lockscreen-request-lock instead of unlock.
> > Could you check it again? Thanks.
> 
> lockscreen.js is already dispatching |lockscreen-request-lock|, what's the
> need to do it again?

Sorry, let's use screenchange event.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8488134 [details] [review]
PR to master

Can you use screenchange instead of dispatching request-lock?

Comment 14

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8488134 [details] [review]
PR to master

Hi Alive,
I updated the code, please kindly check again. Thanks.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8488134 [details] [review]
PR to master

Sorry again, but I don't think keyboard manager need to know the state of lockscreen enabling or not. Why do you need to know that?

Also, does |hide keyboard immediately on screen off(evt.detail.enabled=false)| not fix this issue?

Comment 16

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8488134 [details] [review]
PR to master

Hi Alive,
thanks for advice, this patch would hide keyboard when screen is off.
please kindly check again, thanks!

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8488134 [details] [review]
PR to master

r=me thanks!

Comment 18

[(Inactive after June) George Duan [:gduan] [:喬智]]

Thanks,
merge to master
https://github.com/mozilla-b2g/gaia/commit/cd8a8fe38d77951b375c5d1c8ec2393fc21c33af

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Please request Gaia v2.1 approval on this when you get a chance.

Comment 20

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to 2.1

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Bug 1054126
[User impact] if declined: see attachment 8486144 [details]
[Testing completed]: Yes
[Risk to taking this patch] (and alternatives if risky): None.
[String changes made]:

Comment 21

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/350704775d13bd374540d8cdb4619349433202c0

Comment 22

[Adam Alldredge [:AdamA][Inactive]]

The issue is verified fixed in Flame 2.1 and Flame 2.2:

Flame 2.1 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141008000201
Gaia: d71f8804d7229f4b354259d5d8543c25b4796064
Gecko: 7fa82c9acdf2
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.2 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141008040203
Gaia: 0bc74ce502672cf0265b24cf3a25d117c3de5e71
Gecko: e4cfacb76830
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

The lockscreen appears correctly when locking and viewing it when the user was setting a passcode lock.