Description: If the user enables both the Passcode as well as a Sim Pin, whenever they lock and then unlock their device, there is a black bar at the bottom of the screen. Note: This does not occur when the device is freshly booted, only once the phone has already been on, locked, then unlocked. Additionally, the black bar is larger the fist time the phone is unlocked, and smaller each subsequent time. Repro Steps: 1) Update a Flame device to BuildID: 20140918000204 2) Ensure that the device has a Passcode and Sim Pin (restarting the device to ensure the Sim Pin is applied) 3) From the Homescreen, press the power button to lock the device. 4) Press the power button to unlock the device. Actual: There is an inappropriate black bar at the bottom of the Lock Screen Expected: The Lock Screen is rendered appropriately. Environmental Variables: Device: Flame 2.1 BuildID: 20140918000204 Gaia: 379e68fe729a684fa2fcddb30ea1e65508db73e1 Gecko: 7ff763eb328b Version: 34.0a2 (2.1) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Notes: This issue occurs on both Shallow and Full flash Repro frequency: 8/8 See attached: screenshot, logcat ---------------------------------------------- This issue DOES occur in Flame 2.2 There is a black bar at the bottom of the Lock Screen Environmental Variables: Device: Flame 2.2 Master BuildID: 20140918040210 Gaia: d37950eb09e28aa18d0e01df9ff90574bd4337e0 Gecko: 426497473505 Version: 35.0a1 (2.2 Master) Firmware: V123 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 ---------------------------------------------- This issue also occurs intermittently on the Kit Kat base using a 2.1 Tinderbox non-Engineering build with a repro rate of around 2/8. There is a black bar at the bottom of the Lock Screen. Environmental Variables: Device: Flame v2.1 Build ID: 20140917123004 Gaia: ad374f4b2a07cb5711679322a815f9feadb5cf64 Gecko: b4d5f9314661 Version: 34.0a2 (2.1) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

QAWanted for branch checks.

The bug repros on KK Flame 2.2 and 2.1 Actual result: After awakening the device, the lockscreen will be shifted halfway up. When the user moves the slider to the unlock icon, the passcode screen will show a smaller black bar at the bottom of the screen. Flame 2.2 BuildID: 20140922040649 Gaia: 3802009e1ab6c3ddfc3eb15522e3140a96b33336 Gecko: 5e704397529b Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Flame 2.1 BuildID: 20140922053548 Gaia: 689c4ad4d8c3e4aa95805a2e49ae6cf786a1ae91 Gecko: 185fc54d29c1 Platform Version: 34.0a2 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------------------------------------------------------------------------- The bug does not repro on KK Flame 2.0 Actual result: After awakening the device, the passcode screen renders with no errors. BuildID: 20140922082143 Gaia: 0658006be8a00fdb5931ee15a0aa353a3ab231ba Gecko: dc61f92b855e Platform Version: 32.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

not nomming, visual issue only, no loss of functionality

I do not if this is the cause, or the result, but when screen lock pass code is requested,keyboard layout is not rendered properly (see attachment). Backspace and Cancel keys should be on the same position and change appropriately.

Can you still reproduce this issue?

I am unable to reproduce this issue on either Flame 2.1 or 2.2. Lock screen is displayed properly when both Passcode and SIM Pin are enabled. Environmental Variables: Device: Flame 2.1 (319MB) BuildID: 20141015001201 (Full Flash) Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3 Gecko: 4853208cb48a Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34. Environmental Variables: Device: Flame 2.2 Master (319MB) BuildID: 20141015040201 (Full Flash) Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6 Gecko: 62f0b771583c Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 36.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Closing this as worksforme. Please reopen the issue if encountered again.

This issue is again occurring in the latest builds, but the behavior has changed. This issue now only seems to occur if the Software Home Button is also enabled. Current repro steps: 1) Update a Flame device to BuildID: 20141021040206 2) Enable Software Home Button in the Developer Settings menu. 3) Ensure that the device has a Passcode and Sim Pin (restarting the device to ensure the Sim Pin is applied) 4) From the Homescreen, press the power button to lock the device. 5) Press the power button to unlock the device. This issue occurs on both Flame 2.1 and 2.2 with the v180 and v188 firmware bases. A black bar is present at the bottom of the lockscreen. Environmental Variables: Device: Flame 2.2 Master BuildID: 20141021040206 Gaia: 457a54fc3200b80e4f5e1cd3acaa062309230732 Gecko: 29fbfc1b31aa Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 36.0a1 (2.2 Master) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Environmental Variables: Device: Flame 2.1 BuildID: 20141021001201 Gaia: e458f5804c0851eb4e93c9eb143fe044988cecda Gecko: ee86921a986f Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

[Blocking Requested - why for this release]: Bad user experience with high visibility with Software Home Button. Requesting a window.

Regression window Last working BuildID: 20140722025327 Gaia: 649245c238a043af32acb109b2613f578323f8e1 Gecko: 63f44b4968c2 Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First broken BuildID: 20140722033326 Gaia: e423c3be8d19c9a8a5ae2571f499c36dc6b0df89 Gecko: 6f702709fab6 Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Working Gaia / Broken Gecko = No repro Gaia: 649245c238a043af32acb109b2613f578323f8e1 Gecko: 6f702709fab6 Broken Gaia / Working Gecko = Repro Gaia: e423c3be8d19c9a8a5ae2571f499c36dc6b0df89 Gecko: 63f44b4968c2 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/649245c238a043af32acb109b2613f578323f8e1...e423c3be8d19c9a8a5ae2571f499c36dc6b0df89 B2G Inbound Last working BuildID: 20140721201431 Gaia: 6c85ca2112b45b27b3c4a167de19b0d1d96857ec Gecko: 6e1849b0b978 Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 First broken BuildID: 20140721224728 Gaia: 9f6c4d671e83a40aee220b9c2ed8288a797df408 Gecko: 7359cbd2ea00 Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Working Gaia / Broken Gecko = No repro Gaia: 6c85ca2112b45b27b3c4a167de19b0d1d96857ec Gecko: 7359cbd2ea00 Broken Gaia / Working Gecko = Repro Gaia: 9f6c4d671e83a40aee220b9c2ed8288a797df408 Gecko: 6e1849b0b978 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/6c85ca2112b45b27b3c4a167de19b0d1d96857ec...9f6c4d671e83a40aee220b9c2ed8288a797df40

Broken by Bug 1035739? Can you take a look George?

I can reproduce it on master, but even I revert my own commit, the issue still exist. I will take a look on it. (In reply to Martin Shuman [:Marty] from comment #9) > This issue is again occurring in the latest builds, but the behavior has > changed. This issue now only seems to occur if the Software Home Button is > also enabled. > > Current repro steps: > 1) Update a Flame device to BuildID: 20141021040206 > 2) Enable Software Home Button in the Developer Settings menu. > 3) Ensure that the device has a Passcode and Sim Pin (restarting the device > to ensure the Sim Pin is applied) > 4) From the Homescreen, press the power button to lock the device. > 5) Press the power button to unlock the device. > > This issue occurs on both Flame 2.1 and 2.2 with the v180 and v188 firmware > bases. > A black bar is present at the bottom of the lockscreen. > > Environmental Variables: > Device: Flame 2.2 Master > BuildID: 20141021040206 > Gaia: 457a54fc3200b80e4f5e1cd3acaa062309230732 > Gecko: 29fbfc1b31aa > Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d > Version: 36.0a1 (2.2 Master) > Firmware: V188 > User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 > > Environmental Variables: > Device: Flame 2.1 > BuildID: 20141021001201 > Gaia: e458f5804c0851eb4e93c9eb143fe044988cecda > Gecko: ee86921a986f > Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d > Version: 34.0 (2.1) > Firmware: V180 > User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Regression of bug 1079706

The height the LockScreenInputWindow get is incorrect. I would find why and fix it.

But this is a new symptom, so I don't think it's still a v2.1 issue. Should we open another bug for it?

Hi I cannot reproduce it on latest 2.1. could you provide me first broken 2.1 build? Thanks.

George - the first broken 2.1 build was listed at comment 11 First broken BuildID: 20140722033326 Gaia: e423c3be8d19c9a8a5ae2571f499c36dc6b0df89 Gecko: 6f702709fab6 Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

I cannot reproduce it on below 2.1 branch. Please check it again. BUILDID: 20141026161201

QA-Wanted to check latest 2.1

Yes, I am able to reproduce this issue when SIM PIN, Passcode Lock and Software Home Button is enabled. My STR: 1. Swipe to unlock 2. Type in Passcode 3. At the Sim Pin screen tap the Power button to lock the phone. 4. HOLD down the power button so the Power button menu appears. Results: There is a lot of black screen real estate now showing on the screen. Not just black line but a lot of black area. Then swiping to bring up the Passcode lock screen shows black area on the keyboard as well. Tested with Shallow Flash on 319mb using Engineering builds Repro Rate: 3/5 Environmental Variables: Device: Flame 2.1 KK BuildID: 20141027032141 Gaia: f8378fe1c7f128a3b679201b469a82fca2371828 Gecko: 32a102b8e807 Version: 34.0 (2.1) Firmware: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Ok, after bisect, it should be a regression of bug 1082071.

Hi Michael, For 2.1 case, I think your patch in bug 1082071 has regression like comment 21 after git bisect. Do you have any idea on that? For master case, the behavior actually looks different with 2.1, I file bug 1090018 to trace it.

I'll take a look.

In bug 1023111 we added [1], which was a workaround for the sim pin dialog not scrolling the pin input into view after entering the wrong pin. However, I believe this has been fixed at the form level itself, so we can probably just remove this workaround. 1.) https://github.com/mozilla-b2g/gaia/commit/5d71fa6a5caffe9e3843ac0e8f561c8d94a768f1

Sorry, I didn't mention why the above caused this bug. My patch in bug 1082071 triggers a system-resize whenever we unlock the phone. This system resize causes the sim-pin dialog to resize itself, which calls into the code from bug 1023111. Specifically, this line: document.activeElement.scrollIntoView(false); When the lockscreen passcode is enabled, there is a race condition where document.activeElement sometimes still is the passcode input when instead it should be the sim pin input. Trying to scroll the passcode input into view causes the weird display of the lockscreen mentioned in comment 21.

We really need an integration test for this, but that integration test requires correct mocks for mozMobileConnections, which we don't have yet. Also, the test should land on master instead of just v2.1. So let's fix this here for now to give us breathing room, and add the integration test as part of the effort in bug 1077579. Tim, since you reviewed bug 1023111, can you have a look here?

That was a very old workaround...

(In reply to George Duan [:gduan] [:喬智] from comment #23) > Hi Michael, > For 2.1 case, I think your patch in bug 1082071 has regression like comment > 21 after git bisect. Do you have any idea on that? > > For master case, the behavior actually looks different with 2.1, I file bug > 1090018 to trace it. I'm now seeing a very different and bad issue on master with the same STR. I'll file a new bug.

This fix will need to be backported to master, since right now we are seeing bug 1092282 there.

v2.1: https://github.com/mozilla-b2g/gaia/commit/36d9f52883b420f90b759303609b2d27d6f94f2c

master: https://github.com/mozilla-b2g/gaia/commit/9b274e0101506fc76afa5e0808d4dceb4ee9568b

This issue is verified fixed on Flame 2.1 and 2.2. Result: No black area is observed when following STRs on Comment 9 and Comment 21. Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash) BuildID: 20141103001220 Gaia: 027a7de0c95320cea0579bfd1a4ceef3e9038f34 Gecko: ffecb2be228b Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 34.0 (2.1) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash) BuildID: 20141103040202 Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec Gecko: 5999e92e89ff Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 36.0a1 (2.2) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0