If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

active tab's docshell is not set active when app goes from background to foreground

RESOLVED WORKSFORME

Status

()

Firefox for Android
General
P2
normal
RESOLVED WORKSFORME
6 years ago
a year ago

People

(Reporter: dougt, Assigned: bnicholson)

Tracking

unspecified
ARM
Android
Points:
---

Firefox Tracking Flags

(blocking-fennec1.0 +)

Details

(Reporter)

Description

6 years ago
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.

Comment 1

6 years ago
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.
OS: Mac OS X → Android
Hardware: x86 → ARM
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.

Comment 4

6 years ago
(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 guess there is a relation to bug 734908 here.
Blocks: 734908

Updated

6 years ago
blocking-fennec1.0: --- → ?
blocking-fennec1.0: ? → +
Priority: -- → P2
(Assignee)

Updated

6 years ago
Assignee: margaret.leibovic → bnicholson
(Assignee)

Comment 12

6 years ago
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.
(Assignee)

Comment 13

6 years ago
Doug tried this again today and said the problem is gone, so resolving as WFM.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.