[B2G][System][Lockscreen] The lock screen cannot be bypassed if the user holds down the power button during boot

NEW
Unassigned

Status

Firefox OS
Vendcom
4 years ago
a year ago

People

(Reporter: KTucker, Unassigned)

Tracking

({regression})

unspecified
1.2 C5(Nov22)
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: burirun1 [POVB])

Attachments

(4 attachments, 2 obsolete attachments)

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?
Keywords: qawanted

Updated

4 years ago
QA Contact: sparsons

Comment 2

4 years ago
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
Keywords: qawanted

Updated

4 years ago
blocking-b2g: --- → koi?
Keywords: regression, regressionwindow-wanted
(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?
Flags: needinfo?(ktucker)
(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?
Flags: needinfo?(ffos-product)
This issue was encountered when ad hoc testing and not tied to a specific test case.
Flags: needinfo?(ktucker)
Created attachment 811426 [details]
Lockscreenvideo.mp4
Attachment #807897 - Attachment is obsolete: true
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?
blocking-b2g: koi? → ---
Flags: needinfo?(ktucker)
Keywords: regression, regressionwindow-wanted
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.
Flags: needinfo?(ktucker)
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.
blocking-b2g: --- → koi?
Flags: needinfo?(ffos-product)
Keywords: regression, regressionwindow-wanted

Comment 11

4 years ago
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
Keywords: regressionwindow-wanted
Greg, could you take a look?
Assignee: nobody → gweng
blocking-b2g: koi? → koi+
Flags: needinfo?(gweng)
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.
Flags: needinfo?(gweng)
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?
Flags: needinfo?(ktucker)
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 ktucker@qanalydocs.com 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
Attachment #811426 - Attachment is obsolete: true
Flags: needinfo?(ktucker)
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.

Updated

4 years ago
Target Milestone: --- → 1.2 C5(Nov22)
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.

Comment 28

4 years ago
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]?
Assignee: gweng → nobody
blocking-b2g: koi+ → koi?
Whiteboard: burirun1 → [POVB],burirun1
(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.
Whiteboard: [POVB],burirun1 → burirun1

Updated

4 years ago
Component: Gaia::System::Lockscreen → General
Please take a look
Flags: needinfo?(mwooten111)

Updated

4 years ago
Flags: needinfo?(mwooten111) → needinfo?(mwu)

Comment 36

4 years ago
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.
Flags: needinfo?(mwu)
(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?
Keywords: qawanted

Comment 38

4 years ago
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
Keywords: qawanted
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.
blocking-b2g: koi? → ---
Component: General → Vendcom
Whiteboard: burirun1 → burirun1 [POVB]
You need to log in before you can comment on or make changes to this bug.