str: 1) load http://dl.dropbox.com/u/8727858/physical-events/index.html 2) note that you see acceleration changes 3) put the app in the background 4) put the app in the foreground expected: You should see similar acceleration changes as you did in step (2) actual: no acceleration events are dispatched to the event target (you will not see acceleration changes) If you switch tabs or cause a screen rotation, you will see acceleration changes again. I am guessing that the docshell isn't set to active when we go from background to foreground.
I can't reproduce this. Is it just a maple issue?
I'm able to repro in maple build tinderbox build from earlier this morning; maple would be a dup of bug 732563 I can't repro on nightly build 3/6/2012 using Galaxy Nexus.
mfinkle mentioned on irc: http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1646 this.browser.docShellIsActive should be this.browser.docShell.IsActive I noticed it with this example: http://people.mozilla.org/~mwargers/tests/dom/moznotification.htm after tapping on the second button on that page.
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #3) > mfinkle mentioned on irc: > http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/ > browser.js#1646 > this.browser.docShellIsActive should be this.browser.docShell.IsActive I believe mfinkle was looking into the source of the problem, but for the record, this.browser.docShellIsActive is valid: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml#264
browser.docShellIsActive is valid and is being called correctly on Nightly when switching between tabs.
Hmm, background tabs do not freeze timers (setInterval). They are clamped to 1000ms to improve performance. See bug 633421 for that. So the timer issue is not relevant to chasing this issue.
When an Android activity is backgrounded BUT STILL VISIBLE on screen, onPause() is called and the activity should stop animations and other things that may be consuming CPU. When an activity is backgrounded AND NO LONGER VISIBLE, onStop() is called and the activity should stop everything. https://developer.android.com/guide/topics/fundamentals/activities.html#ImplementingLifecycleCallbacks
Sorry, I'm confused by the answer in comment 7 and I'm not sure that issue that I think is a bug is what this bug is about, so I filed a new bug for it, bug 735246.
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #8) > Sorry, I'm confused by the answer in comment 7 and I'm not sure that issue > that I think is a bug is what this bug is about, so I filed a new bug for > it, bug 735246. Timers should not be suspended, only clamped to 1 sec.
The stock Android browser seems to suspend timers when the application is in the background. Why shouldn't Fennec do that? That way much less cpu is used, so much less power.
I can't reproduce this either. I am encountering some issues with testcase linked here - certain values on the page don't update, or they stop updating after some time. But this doesn't seem to be related to putting Fennec in the background.
Doug tried this again today and said the problem is gone, so resolving as WFM.