Closed Bug 1096311 Opened 8 years ago Closed 5 years ago

[Flame] Power button takes ~5s to turn on screen

Categories

(Firefox OS Graveyard :: Performance, defect)

defect
Not set
normal

Tracking

(tracking-b2g:-)

RESOLVED WONTFIX
tracking-b2g -

People

(Reporter: benfrancis, Unassigned)

References

Details

Attachments

(1 file)

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?
Flags: needinfo?(mwu)
Bug 932698 is now uplifted to 2.1 so we shouldn't need this.
Flags: needinfo?(mwu)
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? → ---
Flags: needinfo?(bfrancis)
I'm still reproducing this on the 2.1 OTA channel :(

Anecdotally, it does seem to happen less often.
Flags: needinfo?(bfrancis)
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 ?
Flags: needinfo?(vwang)
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.
Flags: needinfo?(vwang)
(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.
Flags: needinfo?(bfrancis)
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
Keywords: qawanted
(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?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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.
Flags: needinfo?(bfrancis)
tracking-b2g: --- → -
Firefox OS is not being worked on
Status: REOPENED → RESOLVED
Closed: 8 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.