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.

Restart works as expected on my unagi build 20121212102240.

George, can you find a regression window for this?

I noticed it the first time around Dec 12 on mc.

Raising to P1 -- this is a smoketest blocker.

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.

Good: https://hg.mozilla.org/releases/mozilla-b2g18/rev/7d4da1832dcc

Bisecting tells me bug 814921 is the cause. And indeed, backing it out makes restarting work again.

o_O

The 'animationend' does not fire and thus we're waiting forever or until it does after a couple of seconds.

Pointer to Github pull-request

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.

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?

(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.

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.

(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.

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.

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.