Closed Bug 822392 Opened 12 years ago Closed 12 years ago

"Restart" button not working

Categories

(Firefox OS Graveyard :: General, defect, P1)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)

Status:
VERIFIED FIXED
Milestone:
B2G C3 (12dec-1jan)
Project Flags:
blocking-basecamp +
Tracking Flags:
Tracking Status
firefox19 --- fixed
firefox20 --- fixed
b2g18 --- fixed

People

(Reporter: cjones, Assigned: nrc)

References

Details

(Keywords: regression, smoketest, Whiteboard: [b2g-gfx])

Attachments

(1 file)

Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7105
355 bytes, text/html
timdream
: review+
Details 
STR
 (1) Long-tap power button
 (2) Choose "Restart"

The first press seems to be ignored.  Pressing the button a second time hangs the UI until the emergency code kicks in.
Gecko 7b93aab393cd0ea45f2b1894c969f6c5b55ef083, gaia df14f48088e107a180811ff73357e76e95acf776
I attached GDB a few days ago and saw GC, CC and other regular shutdown work. Maybe something got really slow.
blocking-basecamp: ? → +
Restart works as expected on my unagi build 20121212102240.
George, can you find a regression window for this?
Assignee: nobody → gwright
Whiteboard: [b2g-gfx]
I noticed it the first time around Dec 12 on mc.
Target Milestone: --- → B2G C3 (12dec-1jan)
Raising to P1 -- this is a smoketest blocker.
Keywords: smoketest
Priority: -- → P1
Why didn't the smoketests catch this?
I have seen it intermittently today, but not consistently.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #8)
> Why didn't the smoketests catch this?
I found the reason why the smoketests have not caught this.

If you reboot the phone, and then restart; you won't see the issue.

If you go to the settings app, and then try to restart, it doesn't restart the phone.
If you let the phone sleep and play with apps and then try to restart, it could potentially lock the phone.  I think somewhere along the lines there might be some memory leak or something that's causing this to occur?
Naoki is right, restarting from the lockscreen works fine.

STR:

1) Open the settings app
2) Hold down the power button
3) Click restart

Expected: Should restart
Actual: Hangs for some seconds, shows settings app again, hangs for some seconds, reboots.
Bisecting tells me bug 814921 is the cause. And indeed, backing it out makes restarting work again.
Blocks: 814921
Assignee: gwright → ncameron
The 'animationend' does not fire and thus we're waiting forever or until it does after a couple of seconds.
Comment on attachment 694293 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7105

I noticed we never remove the 'animationend' listener and it thus could execute code twice. Let's not do this.
Attachment #694293 - Flags: review?(timdream+bugs)
Comment on attachment 694293 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7105

As a clean up I can r+ this patch, however I am not sure why is this fixing anything, especially with comment 14?
Attachment #694293 - Flags: review?(timdream+bugs) → review+
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #19)
> As a clean up I can r+ this patch, however I am not sure why is this fixing
> anything, especially with comment 14?

It's not fixing the core issue, just a cleanup patch.
(In reply to Tim Taubert [:ttaubert] from comment #20)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #19)
> > As a clean up I can r+ this patch, however I am not sure why is this fixing
> > anything, especially with comment 14?
> 
> It's not fixing the core issue, just a cleanup patch.

++ for stow away a clean up fix in a blocking+ bug
Sorry for the confusion, it's not caused by bug 814921. Bisecting was quite hard because there was some build bustage in that range and I had to do it again. Currently verifying.
No longer blocks: 814921
The first bad revision is:
changeset:   117599:c16bc9826f53
user:        Nicholas Cameron <ncameron@mozilla.com>
date:        Sat Dec 15 14:39:15 2012 -0800
summary:     Bug 780692; throttle OMTA (rollup patch). r=dbaron,bz a=blocking-basecamp

That's what my last bisection tells me. Unfortunately, the back out doesn't build so I can't really verify this.
Blocks: 780692
(In reply to Tim Taubert [:ttaubert] from comment #23)
> That's what my last bisection tells me. Unfortunately, the back out doesn't
> build so I can't really verify this.

The first suspected bug depends on the currently suspected one, of course. Backing both out makes it work again. Backing only d3ebbae46c23 out does not help so it must be bug 780692.
Setting 'layers.offmainthreadcomposition.throttle-animations' to 'false' doesn't fix this issue.
How does the restart button work in gaia?  That might help us figure out where to look.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #26)
> How does the restart button work in gaia?  That might help us figure out
> where to look.

It's starting two CSS animations and waits for the animationend event for both of these and then calls navigator.mozPower.reboot() or .powerOff().
Restarting works again with the first patch from bug 822231. The animation looks a little different but that may be because I'm missing the second patch which doesn't apply. Looks like we just need to wait for bug 822231?
OK by me.
Depends on: 822231
Just to confirm, the two now r+'ed patches from bug 822231 fix this issue.
I wonder if we should not reboot/powerOff after a timeout instead of waiting for animationend event which may be less reliable.

Just a thought, but what do you think ?
(In reply to Julien Wajsberg [:julienw] from comment #31)
> I wonder if we should not reboot/powerOff after a timeout instead of waiting
> for animationend event which may be less reliable.

Or both -- the animationend trigger is nice and smooth when it's working but if we're still around after 3 seconds (or whatever threshold) just kill it anyway.
Closing based on #30, that's landed now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Dylan> should we file a bug for using setTimeout in addition to the animation events ?
Issue no longer appears to be occurring on an Unagi device running the following build: 

Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/af9270e8f205
Gaia: a78ebf426840b5ef08c0cc3e437ad30aba3e2528
Build: 20130318070202

Verifying as fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: