Martin Shuman [:Marty] Reporter
	Description • 10 years ago

Description:
If the phone is turned off at the time of an alarm, the alarm will then sound at the lockscreen upon the next boot up of the device.  If Software Home Button is enabled on the phone, and this happens, the Alarm pop-up will appear very high on the screen.

Notes:
-This issue does NOT occur if SHB is not enabled.
-SHB is not visible on the screen when the issue occurs.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141031001201
2) Enable Software Home Button on the device in Developer settings.
3) In the Clock app, set an alarm to go off in a few minutes.
4) Turn off the DUT.
5) After the time set for the alarm, turn the DUT back on.
  
Actual:
Alarm pop-up appears very high on the screen.
  
Expected: 
Alarm pop-up appears properly, covering the entire screen.
  
Environmental Variables:
Device: Flame 2.1 (319MB)
BuildID: 20141031001201 (Full Flash)
Gaia: f89c7b12c36572262c9ea76058694a139b1a8634
Gecko: 50d48f8a04c7
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 3/3
See attached: screenshot

---------------------------------------------

This issue does NOT occur on Flame 2.2.
Alarm pop-up appears properly, covering the entire screen.

Environmental Variables:
Device: Flame 2.2 Master (319MB)
BuildID: 20141031061804 (Full Flash)
Gaia: a07994714f0552f89801d6097982308d8b0a1ee1
Gecko: 6bd2071b373f
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 1 • 10 years ago

[Blocking Requested - why for this release]:

Nominating this 2.1? because it is related to the software home button and it looks bad.

	howie [:howie]
	Comment 2 • 10 years ago

Triage: blocker, regression window wanted.

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 3 • 10 years ago

I think what we want here is a 'reverse' regression window, to figure out which patch fixed this in 2.2. It's not clear to me that this is a regression.

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 4 • 10 years ago

Alberto, can you take a look at this?

	Alberto Pastor [:albertopq] Assignee
	Comment 5 • 10 years ago

I couldn't repro with latest pvt 2.1

Gaia-Rev        154da5e17029a51002d5d9b7df39563d509edde6
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3b0c3580a58d
Build-ID        20141105001204
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.alberto.20141104.134458
FW-Date         Tue  4 Nov 2014 14:29:18 GMT
Bootloader      L1TC00011880

Could you please try again to make sure? Thanks!

	Adam Alldredge [:AdamA][Inactive]
	Comment 6 • 10 years ago

I was able to reproduce this issue on the KK base with a nightly 2.1 build. There are some other prerequisites required for this bug to occur. I had to have wi-fi connected, sim pin lock turned on, and lock screen passcode turned on. I am getting it 100% of the time when I have these setup before I follow the repro steps. Software home button does not need to be turned on for the bug to occur as well.

Environmental variables:
Device: Flame 2.1 (319mb)(Shallow Flash)
Build ID: 20141104001202
Gaia: 8b0cf889ae0d48a9eb7ecdcb9b67590de45cc5e5
Gecko: 388b03efe92d
Version: 34.0 (2.1)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

	Adam Alldredge [:AdamA][Inactive]
	Comment 7 • 10 years ago

After further investigation my build from the previous comment was actually on 512mb. My prerequisites work on 512mb. on 319mb those will not cause the issue to repro. to get the issue to repro on 319mb you need Wi-fi, sim pin lock, and SHB all turned on. When Lock screen passcode is enabled the bug will not repro.

	Adam Alldredge [:AdamA][Inactive]
	Comment 8 • 10 years ago

I was unable to reproduce this issue on Flame 2.0 in 319mb or 512mb.

Device: Flame 2.0 (Shallow Flash)
BuildID: 20141105063630
Gaia: e19ba2a049f192a560c6e63a0cc213b0353f1a02
Gecko: 2c2d1f552ff6
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

	Alberto Pastor [:albertopq] Assignee
	Comment 9 • 10 years ago

Sorry, I tried with all possible combinations and memory configurations, and was unable to repro on 2.1. Adding qawanted for having a 3rd opinion. Thanks!

	Adam Alldredge [:AdamA][Inactive]
	Comment 10 • 10 years ago

I am unable to obtain a regression window for this issue. In order for the bug to repro the aloarm has to go off before the lock screen appears. Sometime before September 1st alarms stop going off before the lock screen appears. This prevents me from obtaining a regression window.

Last known Repro:
Device: Flame 2.1
BuildID: 20140901053214
Gaia: e7d31f0e9b6b19d9b484eeec8fb980718bc40d79
Gecko: 532b5fb77ba1
Version: 34.0a1 (2.1) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First known Blocked:
Device: Flame 2.1
Build ID: 20140829133958
Gaia: c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df
Gecko: eed9fe35a00d
Version: 34.0a1 (2.1)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

	Marcia Knous [:marcia]
	Comment 11 • 10 years ago

I was able to reproduce this on Flame, but I had to invoke all the conditions in Comment 6.

Gaia   9658b93b412bdcc0f953d668e8c8e68318c99fb8
SourceStamp 76880403db44
BuildID 20141106001204
Version 34.0
v188

I frankly am not sure whether this should be a blocker. Agreed it doesn't look good, but you do still get the notification on the lockscreen.

	Jayme Mercado [:JMercado] (Inactive 3/4/2016)
	Comment 12 • 10 years ago

Comment 11 seems to have satisfied the qawanted keyword from comment 9.  Removing the tag for now, but feel free to add again if you disagree.

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 14 • 10 years ago

The problem is really hard to reproduce because it is a race between the keyboard and the lockscreen. What happens is this:

1.) System boots.
2.) Sim Pin dialog gets displayed, and calls focus on it's input [a].
3.) The lockscreen opens.
4.) Keyboard manager sees that the lockscreen is opened, and checks to see if the keyboard is active. Since it is not active yet, it does not remove focus from the sim pin input [b].
5.) Alarm fires, and alarm attention screen gets added to the DOM.
6.) Keyboard finally pops up, and causes a system resize [c], which causes the alarm app window to get resized according to the keyboard height. This results in the weird alarm screen display bug.

a.) https://github.com/mozilla-b2g/gaia/blob/4c159e75a1568afbbf0c83c1235ec56facfbe87d/apps/system/js/simcard_dialog.js#L115
b.) https://github.com/mozilla-b2g/gaia/blob/4c159e75a1568afbbf0c83c1235ec56facfbe87d/apps/system/js/keyboard_manager.js#L449
c.) https://github.com/mozilla-b2g/gaia/blob/4c159e75a1568afbbf0c83c1235ec56facfbe87d/apps/system/js/layout_manager.js#L129


Alive, I think the problem here is that the keyboard manager doesn't unfocus the sin pin input when the lockscreen is opened since it hasn't had time yet to activate the keyboard. My proposed solution is just to always unfocus any input when opening the lockscreen regardless of keyboard state. Thoughts?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 15 • 10 years ago

Comment on attachment 8521087 [details] [review]
[Gaia PR] remove input focus when lockscreen opens

Michael, good investigation.
However the root cause you mentioned is already fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1079748, could you confirm again? I don't think we need a master patch if the root cause is true.

For v2.1, if we are not able to uplift bug 1079748, could we dismiss keyboard on attentioncreated event in keyboard manager instead of touching inputmethod api in lockscreen?

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 16 • 10 years ago

Alberto, want to take a look at what Alive suggested in comment 15? I'll sync up with you tomorrow morning PST to see where we are.

	Alberto Pastor [:albertopq] Assignee
	Comment 17 • 10 years ago

Just tried alive's suggestion, and it doesn't seem to fix the problem in 2.1. I'll keep investigating

	Alberto Pastor [:albertopq] Assignee
	Comment 18 • 10 years ago

It seems Michael's suggestion fixes the problem, and it looks reasonable. What do you think?

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 19 • 10 years ago

Comment on attachment 8521339 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26059

works for v2.1

	Alberto Pastor [:albertopq] Assignee
	Comment 20 • 10 years ago

Comment on attachment 8521339 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26059

If you are ok with the approach, could you please r? Thank you!

	Alberto Pastor [:albertopq] Assignee
	Comment 21 • 10 years ago

Comment on attachment 8521339 [details] [review]
Link to Pull Request: https://github.com/mozilla-b2g/gaia/pull/26059

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): -
[User impact] if declined: Alarms when passcode and SIM pin enabled will take only half of the screen on start up.
[Testing completed]: Adapted unit tests for acomodate the simple change.
[Risk to taking this patch] (and alternatives if risky): This is the lowest risk approach for fixing this. One liner that only applies to 2.1. Master is already fixed with a more complex solution.
[String changes made]: -

	Alberto Pastor [:albertopq] Assignee
	Comment 22 • 10 years ago

2.1 only patch. Fixed in 2.2

	Yeojin Chung [:YeojinC]
	Comment 23 • 10 years ago

This issue still reproduces on Flame 2.1.

Result: The alarm does not fill up the whole screen.

Device: Flame 2.1 (319mb, KK, Shallow Flash)
BuildID: 20141117001201
Gaia: 81160ad79e5b4c21967418dd63f1a1d08d77924e
Gecko: 3572aa3e6766
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

	Yeojin Chung [:YeojinC]
	Comment 24 • 10 years ago

(In reply to Yeojin Chung [:YeojinC] from comment #23)
> This issue still reproduces on Flame 2.1.
> 
> Result: The alarm does not fill up the whole screen.
> 
> Device: Flame 2.1 (319mb, KK, Shallow Flash)
> BuildID: 20141117001201
> Gaia: 81160ad79e5b4c21967418dd63f1a1d08d77924e
> Gecko: 3572aa3e6766
> Version: 34.0 (2.1) 
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Correction: I noticed that this patch is not uplifted yet. I will verify it once the patch is uplifted.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 25 • 10 years ago

v2.1 https://github.com/mozilla-b2g/gaia/commit/60a529ed220673d2a893801b56cfa7531baeb9ea

	Sue
	Comment 26 • 10 years ago

This issue has been verified successfully on Flame 2.1
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.1 versions:
Gaia-Rev        afdfa629be209dd53a1b7b6d6c95eab7077ffcd9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/dc3018cbdbe6
Build-ID        20141123001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141123.035029
FW-Date         Sun Nov 23 03:50:40 EST 2014
Bootloader      L1TC00011880