Closed Bug 1096311 Opened 8 years ago Closed 5 years ago
[Flame] Power button takes ~5s to turn on screen
STR: * Leave the Flame with the screen turned off for a couple of minutes * Press the power button Expected: * The screen comes on immediately Actual: * Takes ~5s for anything to happen Reproduced on 2.1 from today's OTA update, but this bug has been around for a while.
Bug 932698 landed on both master and 2.1. I thought that should have solved these issues for good.
See Also: → 932698
I don't see any evidence that bug 932698 actually landed on 2.1. I think bug 932698 is just marked incorrectly.
Do we need to block here or just get bug 932698 uplifted to 2.1?
Bug 932698 is now uplifted to 2.1 so we shouldn't need this.
Okay, I've cleared 2.1?. Ben, can you verify this was fixed by bug 932698 once it is available in a build on your device?
blocking-b2g: 2.1? → ---
I'm still reproducing this on the 2.1 OTA channel :( Anecdotally, it does seem to happen less often.
Still reproducing on 2.1 OTA channel on the Flame, our reference device. [Blocking Requested - why for this release]: This creates a very frustrating user experience every time I want to use the phone.
blocking-b2g: --- → 2.1?
NI :viral here to help with this as bug 932698, apparently did not help here. Is there an easy workaround e can land ? Also is this a recent 2.1 regression ?
I try two devices in my hand but can not reproduce it so far. (at least 30 times in each device) I use the v18D as base image and update gecko/gaia to latest 2.1 in PVT. Here's the version info: Gaia-Rev 6957ac8a322234ec99c8abb7cc18dc6a2e0176db Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6600eba54256 Build-ID 20150113161204 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental 65 FW-Date Mon Dec 15 18:51:29 CST 2014 Bootloader L1TC000118D0 Maybe we can have some specific version with higher reproduce rate for us to find out the root cause.
(In reply to viral [:viralwang] from comment #9) > Created attachment 8548729 [details] > video about wake up time > > I try two devices in my hand but can not reproduce it so far. > (at least 30 times in each device) > I use the v18D as base image and update gecko/gaia to latest 2.1 in PVT. > > Here's the version info: > Gaia-Rev 6957ac8a322234ec99c8abb7cc18dc6a2e0176db > Gecko-Rev > https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6600eba54256 > Build-ID 20150113161204 > Version 34.0 > Device-Name flame > FW-Release 4.4.2 > FW-Incremental 65 > FW-Date Mon Dec 15 18:51:29 CST 2014 > Bootloader L1TC000118D0 > > Maybe we can have some specific version with higher reproduce rate for us to > find out the root cause. OK, I am clearing the nom in that case. Ben, I am not sure if you are using an engg build or your own build. So it will help if you can try this on a latest pvt build(per comment #9) to be in sync with QA and renom if you can reproduce
blocking-b2g: 2.1? → ---
Bhavana, I was using the production build for flame. Update: I am now using a clean flash of a v188 base image + shallow flash of latest 2.2 production build. I can still consistently reproduce the bug.
blocking-b2g: --- → 2.2?
Flagging Ben to see if he can reproduce on a full flash on 188.
Same problem here randomly w/ ZTE openC FR, FFOS 2.1 Must press 2 or 3 times to "wake up" the phone
The incoming beta build N°20150225161604 (http://builds.firefoxos.mozfr.org/openc/temp/2.1/update-20150225161604.zip) "seems" (after more than 72h and 3 reboot) to fix the problem on my ZTEopenC FR... Wait & see...
triage: this should be blocking as long as we can actually reproduce it.
blocking-b2g: 2.2? → 2.2+
Component: General → Performance
qawanted to check if this happens in v18D
(In reply to howie [:howie] from comment #17) > qawanted to check if this happens in v18D This does NOT happen on v18D + shallow flash latest 2.2 nightly production build. I've tried 30+ times with no repro. I also tried the set up on comment 11 with no repro. Tested on: (repro rate: 0/30) Device: Flame 2.2 (shallow flash 319MB memory) BuildID: 20150305002528 Gaia: 89af288bad6751248ff84504fa898206fee127fe Gecko: 6d8d294aa8f3 Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 (repro rate: 0/10) Device: Flame 2.2 (shallow flash 319MB memory) BuildID: 20150305002528 Gaia: 89af288bad6751248ff84504fa898206fee127fe Gecko: 6d8d294aa8f3 Version: 37.0 (2.2) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Minus it because we can't reproduce it with 18D.
blocking-b2g: 2.2+ → ---
Maybe we can close it now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
I think this is a real bug still, but vendors are working around it. No need to block at this point, but worth fixing if we can.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can still reproduce this on my dogfood device which I'm pretty sure is v18D plus shallow flash 2.2.
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 8 years ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.