Created attachment 807897 [details] Lockscreenvideo.wlmp Description: If the user turns on the phone while plugged into the computer and holds down the power button for 5 seconds during the boot process, they cannot bypass the lock screen. Repro Steps: 1) Updated to Buri Build ID: 20130916040205 2) Plug the phone into the computer via USB. 3) Hold down the power/lock button on the top of the phone and tap "Power off". 4) After the phone powers off, tap and hold the Lock/Power Button to turn the phone back on. Continue to hold down the power button for at least another 5 seconds after the phone turns on. 5) After the phone boots up, try to swipe the lock screen to unlock it. Actual: The user cannot bypass the lock screen if they hold down the power button for 5 seconds when turning on the phone while plugged into the computer. Expected: The user can bypass the lock screen after powering on the phone while it is plugged into the computer. Environmental Variables Build ID: 20130916040205 Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9 Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb Platform Version: 26.0a1 Notes: Repro frequency: (75%) See attached: (video) The user can work around this issue by unplugging the phone from the computer, pressing the top lock button and then waking the phone up again. The lock screen will then function as intended.
Does this reproduce on 1.1?
Unable to reproduce this on Leo 1.1 Build ID: 20130924041200 Comm and Moz RIL Environmental Variables Build ID: 20130924041200 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c6fcfe6a2ad0 Gaia: ff474390146bb8a5b0cce783f8036995fba9fb85 Platform Version: 18.1
(In reply to ktucker from comment #0) > The user can bypass the lock screen after powering on the phone while it is > plugged into the computer. Where is the expectation come from? Is there any feature spec on this?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #3) > (In reply to ktucker from comment #0) > > The user can bypass the lock screen after powering on the phone while it is > > plugged into the computer. > > Where is the expectation come from? Is there any feature spec on this? One question we should ask is what MozTrap test case this comes from. Then, that can point us at the user story. I'm guessing this is from some 1.1 USB Mass Storage user story. I'll dig around to see what the requirements were around this.
Also adding needinfo to comment 4 - what's the expected behavior from a product perspective?
This issue was encountered when ad hoc testing and not tied to a specific test case.
Created attachment 811426 [details] Lockscreenvideo.mp4
I'm going to pull the nom & regression keywords until we get proof from product that this is a bug. I can't tell at this point why this is a bug at this point. ktucker - Can you explain more why this is a bug?
The screen on the phone will not respond to any sort of touch input so the user cannot bypass the lock screen. The end user may think that something is wrong with their phone.
Okay. So the problem here is that if you hold the power button past 5 seconds on power on with the computer plugging into USB, touch events won't work on the lockscreen. That sounds quite bad.
This issue started to occur on the 7/13 Buri 1.2 Build ID: 20130713030204 Gaia fd4a4675ec44ab459b49b17606557024b09dbefe SourceStamp 32c3ccd8946c BuildID 20130713030204 Version 25.0a1 Last Working Buri 1.2 Build ID: 20130712030200 Gaia d94ed01a27125ea8dc91b9f16805411e2d2cc708 SourceStamp b44898282f21 BuildID 20130712030200 Version 25.0a1
Greg, could you take a look?
Well, I've found that it can be reproduced on Unagi with the recent master as well. So this seems a general bug rather a device related issue.
I'll take a look to pin down the root cause first.
The video had gone. It is unavailable now. Can the reporter update load it again?
I suspect that this bug not only affects the lockscreen, but the whole system. Because even the menu invoked by long-pressing the power button doesn't accept any touch events. I would try to by-pass the lockscreen in such situation to check if the whole system is freezing, too. By the way, the symptom is similar to a B2G desktop bug described in 891882, but maybe it's irrelevant due to the difference of platforms.
I have tried to reproduce it on a Buri device with 20131017040202 build, version 27.0a1, and this bug just doesn't appear. I'll fallback to the build mentioned and try again, to see what happened.
Well, after flashed to 20130916040205, my Buri won't boot anymore... I firstly need to spend some time to solve this.
Fallback to the 20130916040205 build, but it's still unable to reproduce the bug. If firstname.lastname@example.org update the video again, reproducing it may become more possible. Beside that, the booting in the newest build seems different from the old build, and I can't reproduce it on the new build, too. So maybe a newer build solve it implicitly? I'll check this after the video become available again.
Greg - A bit confused. Didn't you reproduce the bug in comment 13? Just wondering if you've seen bug generally already or if you haven't seen the bug yourself yet.
I can only reproduce this on Unagi once and other tries are all failed. So after that I thought that I should better focus on Buri. However, with the Buri device I got today I can't reproduce it easily, even with the build mentioned in the summary. So I think I need to follow the video precisely to make sure I didn't do anything wrong.
Created attachment 820424 [details] CannotBypassLockscreen.mp4
I attached a new video. STR: 1) While the phone is "ON" plug the phone into the computer. 2) After the phone is plugged into the computer, hold down the "Power Button" and power off the phone. 3) When the phone shows the "Battery Charging" screen, hold down the "Power Button" to turn on the phone. Do not let go of the "Power Button"! 4) When the Firefox logo appears on the screen continue to hold down the "Power Button" for "5 more seconds" and then release the "Power Button". 5) Try to unlock the lockscreen when it appears. Notice the lockscreen will not respond to the user's touch input. 100% Repro Rate I reproduced this issue on the latest Buri v 1.2.0 COM RIL Environmental Variables Device: Buri v 1.2.0 COM RIL Build ID: 20131022004000 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/7453a764f9a9 Gaia: 00d5964eabf95a6a8a632420dfa36fc76dcbc9b7 Platform Version: 26.0a2 RIL Version: 01.02.00.019.082
Ok I got it, thanks. I'll try it as soon as possible.
Created attachment 820853 [details] Cannot reproduce on this Buri I've found this bug can't be reproduced on my Buri, and an attached video shows the situation. I'm sure that I used the same build: 26.0a1, 20131022004000, 00d5964eabf95a6a8a632420dfa36fc76dcbc9b7 The most different point is that my Buri bootstrap without the Charging phase. It only display screen black. And the fox animation is also missing. I will try this on other devices to check if this bug is actually a device related bug, which may require me spending lots of time to pin down the root cause and find a solution.
(In reply to Greg Weng [:snowmantw] from comment #25) > Created attachment 820853 [details] > Cannot reproduce on this Buri > > I've found this bug can't be reproduced on my Buri, and an attached video > shows the situation. > > I'm sure that I used the same build: 26.0a1, 20131022004000, > 00d5964eabf95a6a8a632420dfa36fc76dcbc9b7 > > The most different point is that my Buri bootstrap without the Charging > phase. It only display screen black. And the fox animation is also missing. > > I will try this on other devices to check if this bug is actually a device > related bug, which may require me spending lots of time to pin down the root > cause and find a solution. Did you try reproducing this on a pvtbuild by any chance? I'm wondering if this could potentially be a bug that only shows up in nightly builds, rather than builds pushed to the device through make in the Gaia repository.
I flashed my device with PVT builds. I have tried this with both the newest (master) Gaia and Gecko 27.01a build and the older version specified by the reporter. However, there is no luck to reproduce it on these build. I'll try it on other Buri(s) later.
Created attachment 821147 [details] logcat (In reply to Greg Weng [:snowmantw] from comment #25) > > The most different point is that my Buri bootstrap without the Charging > phase. It only display screen black. And the fox animation is also missing. > This is probably important. I was able to reproduce this issue on Buri running the latest aurora build - should hold down power button for 5-6 sec after Firefox animation screen appeared (sounds silly but it helps counting :) - one_one_thousand_two_one_thousand_..._five_one_thousand), the animation should continue for another sec or so, then solid Firefox OS screen appears and finally locked screen, which I was not able to unlock. I had a chance to grab a logcat, hopefully it might be helpful here. And it didn't reproduce 100% to me either, I'd say 50% Also, this issue might be easily recoverable by turning screen on and off (pressing power button, but not longpress) BuildID: 20131023004005 Gaia: 1ca623e7a79a9653b54a45ef7f8bb03b8d7100fc Gecko: bb33e2fe109c Version: 26.0a2 Firmware Version: US_20131015
Created attachment 821419 [details] logcat-successful-unlock In the log file I didn't find any notable differences between the failed one and the successful one I've attached. However, I must admit that I'm not an expert of parsing logs, and maybe some guru can find the glitches.
One line didn't appear in the log of the successful result is this: 10-23 10:35:28.749: I/Gecko(185): Settings lock not open!
Finally! After a full flash from the partner's build, the problem now is reproducible. What I've done is to keep the partner's firmware, and flash it shallowly to update my Gecko and Gaia. Now the charging phase is back and the symptom now is reproducible. So far the situation is: 1. Mozilla builds are OK (without/unable to reproduce the problem) But they all comes without the Charging phase, which may be another bug 2. Broken on Partner build date 20131015 + BuildID: 20131023004005 Gaia: 1ca623e7a79a9653b54a45ef7f8bb03b8d7100fc Gecko: bb33e2fe109c Version: 26.0a2 I now suspect that some different things between these two builds make the device in trouble. And as I mentioned earlier, I will check whether the problem affects only the lockscreen, or even the whole system (because the menu invoked by long pressing the power button is also unclickable).
I've bound the `LockScreen.unlock()` on the volume up button in the '/apps/system/js/hardware_buttons.js' to bypass the lockscreen, and found the whole sustem is insensible to any touch events. It seems the touch events now got malfunctional. So far we can prove that: 1. This problem affects not only the lockscreen 2. It only happens on some specific build(s) 3. Such symptom maybe caused by the broken touch events
(In reply to Greg Weng [:snowmantw] from comment #31) > 1. Mozilla builds are OK (without/unable to reproduce the problem) > But they all comes without the Charging phase, which may be another bug [POVB]?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #33) > (In reply to Greg Weng [:snowmantw] from comment #31) > > 1. Mozilla builds are OK (without/unable to reproduce the problem) > > But they all comes without the Charging phase, which may be another bug > > [POVB]? I don't think this is POVB - comment 11 points at the fact that this was working before. It's more likely that the regression probably happened at the lower level - in Gonk. There were Gonk changes made in the 1.2 timeframe. Pulling POVB because regression range points to the fact that this did work previously, leading me to believe that this might be a Gonk bug.
Please take a look
I have no idea. This sounds like POVB. There was input code changes in 1.2, but they landed well after the reported regression range in comment 11. The part of gonk that controls input events is all in the kernel, and that's all device specific.
(In reply to Michael Wu [:mwu] from comment #36) > I have no idea. This sounds like POVB. There was input code changes in 1.2, > but they landed well after the reported regression range in comment 11. The > part of gonk that controls input events is all in the kernel, and that's all > device specific. Thanks for the clarity. Two questions to close this out in a QA Wanted request: 1. Can someone check if this reproduces on a Buri 1.1 build? 2. Can someone check if this reproduces on a Leo 1.2 build?
This issue does not reproduce on Buri 1.1 Build ID: 20131101041316 Gaia 39b0203fa9809052c8c4d4332fef03bbaf0426fc SourceStamp 31fa87bfba88 BuildID 20131101041316 Version 18.0 This issue also does not reproduce on Leo 1.2 Build ID: 20131101004000 Gaia e717aec947571f5daf923c040a82f9f0719bb526 SourceStamp 54de309e18a9 BuildID 20131101004000 Version 26.0
Weird. I guess this is a base image issue with Buri. Probably can't block on it then as it's out of control, but we should keep an eye out for this when a new 1.2 Buri base image becomes available.