Gaia f7b408fe7e40a6e783e3f29c5cea5ec5ba5349ae SourceStamp 70f21fad60a4 BuildID 20131108040203 Version 28.0a1 Helix 1. install OEM build, flash gecko/gaia as per above. 2. let the device sleep 3. tap the power to wake it Expected: lockscreen appears Actual: the screen is still all black, if you swipe where the lock is located to unlock the device the device will wake and unlock

This issue started to occur on the Helix 1.2 Build ID: 20130916040205 Gaia a0079597d510ce8ea0b9cbb02c506030510b9eeb SourceStamp c4bcef90cef9 BuildID 20130916040205 Version 26.0a1 Last Working Helix 1.2 Build ID: 20130915040205 Gaia 3f51f302c3a0c57d8bad482ec7ee86b2819389fb SourceStamp 9366ee039645 BuildID 20130915040205 Version 26.0a1

Helix is target on v1.1, we don't expect it can run on v1.2 or v1.3. There is a bug 933711 on v1.1 that look like a dup of this.

I take it the question being asked here is to check if this reproduces on 1.1.

This issue does not reproduce on Helix 1.1HD Build ID: 20131119042200 Gaia 85f9a33cc95e04f5fd962ec37fa39eb622136f45 SourceStamp fa03d0230e50 BuildID 20131119042200 Version 18.0

Moving back to 1.3? as this bug is a regression to 1.3

Can someone check if this reproduces on 1.2?

This issue also reproduces on Buri 1.2 Build ID: 20131119004006 Gaia 9439907a255e04de4c33493fe03d6670c8256e2f SourceStamp fe2a7f0db27b BuildID 20131119004006 Version 26.0

Blocking on this for blocking a critical use case of the power button of the phone

This also reproduces in Ikura V1.2 Build ID: 20131114004004

mwu - Do you have any ideas what could cause a bug like this? Could it be a gaia, gecko, or gonk bug?

(In reply to Juan Perez-Bedmar [:juanpbf] @ Madrid from comment #9) > This also reproduces in Ikura V1.2 Build ID: 20131114004004 Adding dep for 1.2 pre-testing.

Can we get a logcat when this occurs?

Add qawanted to help getting a logcat.

I can no longer repro this issue on the Helix 1.3 Build ID: 20131205040201 Gaia 1dd0e5c644b4c677a4e8fa02e50d52136db489d9 SourceStamp 725c36b5de1a BuildID 20131205040201 Version 28.0a1

Tim, this might be already fixed, but can you assign an engineer to confirm on Helix?

(In reply to Sarah Parsons from comment #14) > I can no longer repro this issue on the Helix 1.3 Build ID: 20131205040201 > > Gaia 1dd0e5c644b4c677a4e8fa02e50d52136db489d9 > SourceStamp 725c36b5de1a > BuildID 20131205040201 > Version 28.0a1 Does it still reproduce on 1.2?

This is not a lock screen issue but rather a Helix-specific porting issue, AFAIK. Please do not switch the component back to lock screen again. QA, please try to reproduce this on v1.2 and loop graphic/system engineers. Marco, is this issue already under the radar?

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #17) > This is not a lock screen issue but rather a Helix-specific porting issue, > AFAIK. Please do not switch the component back to lock screen again. > > QA, please try to reproduce this on v1.2 and loop graphic/system engineers. > > Marco, is this issue already under the radar? It's not Helix-specific. comment 7 already confirmed this also reproduces on Buri 1.2.

This issue still reproduces on the Helix 1.2 Build ID: 20131206004002 Gaia d48df33cbdae2063f12b09e3dca07ff7a2f2a3cc SourceStamp fd0302696c57 BuildID 20131206004002 Version 26.0

I am unable to get a logcat because the logcat stops recording when the phone goes to sleep which is a required step. (In reply to Sarah Parsons from comment #19) > This issue still reproduces on the Helix 1.2 Build ID: 20131206004002 > > Gaia d48df33cbdae2063f12b09e3dca07ff7a2f2a3cc > SourceStamp fd0302696c57 > BuildID 20131206004002 > Version 26.0

(In reply to Sarah Parsons from comment #19) > This issue still reproduces on the Helix 1.2 Build ID: 20131206004002 > > Gaia d48df33cbdae2063f12b09e3dca07ff7a2f2a3cc > SourceStamp fd0302696c57 > BuildID 20131206004002 > Version 26.0 I guess what that means is that some patch on trunk fixed this bug, but wasn't uplifted to 1.2.

Let's try getting a reverse regression window here. What that means is: Find out when this started working on 1.3 & the last time it failed on 1.3.

The last broken build was Helix 1.3 Build ID: 20131128040201 Gaia 0d57ec2801ae125ec855a19cf956ab118660d694 SourceStamp a5e7f611546f BuildID 20131128040201 Version 28.0a1 First build the issue stopped occurring was Helix 1.3 Build ID: 20131129053350 Gaia 09d1f63762aaf645b5b6642d218b40f069b77562 SourceStamp e9337081c744 BuildID 20131129053350 Version 28.0a1

This was likely fixed by Re-Implementation of the Lockscreen in bug 919410 for 1.3.

(In reply to Jason Smith [:jsmith] from comment #24) > This was likely fixed by Re-Implementation of the Lockscreen in bug 919410 > for 1.3. Actually, that doesn't look right. That bug isn't part of the Gaia regression range.

Reverse Regression Range Push Log: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a5e7f611546f&tochange=e9337081c744

(In reply to Jason Smith [:jsmith] from comment #26) > Reverse Regression Range Push Log: > > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=a5e7f611546f&tochange=e9337081c744 Hmm...this is going to be hard diagnose based on looking at the push log. Can someone get a logcat when this bug reproduces?

(In reply to Jason Smith [:jsmith] from comment #27) > (In reply to Jason Smith [:jsmith] from comment #26) > > Reverse Regression Range Push Log: > > > > http://hg.mozilla.org/mozilla-central/ > > pushloghtml?fromchange=a5e7f611546f&tochange=e9337081c744 > > Hmm...this is going to be hard diagnose based on looking at the push log. > > Can someone get a logcat when this bug reproduces? Just realized logcat isn't possible, since logcat is disabled when the screen is locked.

Hi, Naoki-san, Sorry. I changed the title because the bug not only happened on helix but also can reproduce on other devices. If you feel it is inappropriate, please feel free to change it. Many thanks.

Might be related to bug 920804? In the bug 933711, I resolve similar issue by back-porting bug 920804.

Thanks for Morris's update. The patch landed to master (v1.3) and uplifted to 1.1.0hd already.

Because 1.2 is going to be finished, should we mark this bug from koi+ to 1.3+? Thanks.

(In reply to Kevin Hu [:khu] from comment #32) > Because 1.2 is going to be finished, should we mark this bug from koi+ to > 1.3+? Thanks. Hi, I think this is quite serious issue, I'd keep koi+ (not moving to 1.3)... Thnks! David

(In reply to Marco Chen [:mchen] from comment #31) > Thanks for Morris's update. > > The patch landed to master (v1.3) and uplifted to 1.1.0hd already. Note - the combination of both of those patches don't match the regression range above. bug 920804 landed on 10/26/2013 & bug 933070 landed on 11/5/2013. The regression range indicates this would have been fixed by something that landed on 11/28/2013.

yes, we should backport bug 920804 and bug 933070 to 1.2, since they only landed on gecko27 and 28.

Try run with the patches rebased: https://tbpl.mozilla.org/?tree=Try&rev=a79bf7a7a488

... and this one at least compiled locally: https://tbpl.mozilla.org/?tree=Try&rev=958d79598ba9

I pushed both to b2g26: remote: https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/cd6aa18208e6 remote: https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8f277371699d

(In reply to Fabrice Desré [:fabrice] from comment #38) > I pushed both to b2g26: > remote: https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/cd6aa18208e6 > remote: https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8f277371699d Should we close this out if this is landed on b2g26?

Per Fabrice, This was backported 3 days ago, should be fixed now.