Closed Bug 735246 Opened 12 years ago Closed 12 years ago

Timers are not suspended after tapping on the Android home button

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-fennec1.0 -, fennec-)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
blocking-fennec1.0 --- -
fennec - ---

People

(Reporter: martijn.martijn, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

testcase
1.01 KB, text/html
Details
Attached file testcase — 
See url testcase, steps to reproduce:
- Tap on the 'doe notification interval 1 second' button
- Tap on the 'Allow' button of the notifications doorhanger prompt multiple times until the notifications are allowed permanently on that site.
- Tap on the Android home button to close Fennec
- Reopen Fennec after 10 seconds or so

Expected result:
- While Fennec is closed, you shouldn't get any new notifications, after reopening Fennec, the seconds counter shouldn't have incremented by 10 seconds.

Actual result:
- Notifications keep appearing, after reopening Fennec, you'll notice that the counter is incremented by 10 seconds.

The stock browser seems to supend the timers just fine, so the counter stops when the browser is closed.

This is tested on the Samsung Galaxy Nexus, Android 4.0.2.
Timers should not be suspended, only clamped to 1 sec. See bug 633421.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
What does this have to do with bug 633421?

I'm not talking about inactive tabs here, I'm talking about having the application 'closed'. So this is not about background tabs, but the application as a whole.

The stock Android browser is suspending timers in that case, making it much less power hungry as Fennec, afaik.
tracking-fennec: --- → ?
blocking-fennec1.0: --- → ?
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #2)
> What does this have to do with bug 633421?
> 
> I'm not talking about inactive tabs here, I'm talking about having the
> application 'closed'. So this is not about background tabs, but the
> application as a whole.

But the application is not closed, just in the background. The browser tabs should be inactive, but 'inactive' means the timers keep going.

> The stock Android browser is suspending timers in that case, making it much
> less power hungry as Fennec, afaik.

We can keep this bug open, but you'll need to move this to a better component I think. Unless Gecko has the ability to freeze timers, Fennec can't do much here.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I guess this depends on bug 384412 then.
Assignee: nobody → general
Component: General → JavaScript Engine
Depends on: js-unwind
Product: Fennec Native → Core
QA Contact: general → general
> Depends on: 384412

I don't think we need bug 384412.

> Unless Gecko has the ability to freeze timers, Fennec can't do much here.

If Gecko doesn't currently expose this capability to Fennec, it should be trivial to do, given that we already throttle timers for background tabs.   "Freezing" a timer is just applying a throttle with callback frequency 0.
Ok, I guess there might also be a relation to bug 734908 here.
This just showed up in JS, which makes me think someone wants us to do something. But the discussion above is pretty wide-ranging. What's the specific thing that's wanted?
(In reply to David Mandelin from comment #7)
> This just showed up in JS, which makes me think someone wants us to do
> something. But the discussion above is pretty wide-ranging. What's the
> specific thing that's wanted?

Sounds to me like: When Fennec is in the background on Android, suspend all timeouts on all pages.
Assignee: general → nobody
Component: JavaScript Engine → DOM: Core & HTML
QA Contact: general → general
Could Fennec just use DOMWindowUtils::SuspendTimeouts() ?
(In reply to Olli Pettay [:smaug] from comment #9)
> Could Fennec just use DOMWindowUtils::SuspendTimeouts() ?

We can look into it.

Moving back to "Fennec Native". Wheeeeee.
Component: DOM: Core & HTML → General
Product: Core → Fennec Native
QA Contact: general → general
Depends on: 736311
Bug 736311 will clamp timers to 1 sec. That is what we want.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
(In reply to Mark Finkle (:mfinkle) from comment #11)
> Bug 736311 will clamp timers to 1 sec. That is what we want.

It is?  Why do you want to run timers at all, in any tab, while Fennec is not in the foreground?
(In reply to Justin Lebar [:jlebar] from comment #12)
> (In reply to Mark Finkle (:mfinkle) from comment #11)
> > Bug 736311 will clamp timers to 1 sec. That is what we want.
> 
> It is?  Why do you want to run timers at all, in any tab, while Fennec is
> not in the foreground?

Out of concern that we'd be breaking a webapp or site using those timers for some reason. We are (will be) firing the page visibility events when going into the background and the website could suspend it's own timers.

If we find power and cpu usage is being negatively impacted by allowing timers to run every second, we can re-consider the decision.
(In reply to Mark Finkle (:mfinkle) from comment #13)
> If we find power and cpu usage is being negatively impacted by allowing
> timers to run every second, we can re-consider the decision.

One can trivially create a page which causes this, of course.  Do you mean, if we observe this in the wild?  I'm sure I could find something like this without much trouble.  For example, new sites refresh themselves periodically.  Do we want your news site refreshing itself periodically while your phone is asleep in your pocket because Fennec happens to be alive in the background?

> Out of concern that we'd be breaking a webapp or site using those timers for some reason.

I'm not sure exactly how this breakage would occur, exactly (we're of course going to restart the timers when Fennec launches again), but I'm much more concerned about silently breaking a user's phone than about breaking a poorly-designed webpage.
I have the same concerns as jlebar.

I don't think a backgrounded activity (i.e. Activity.onStop() has been called) should be using any CPU cycles. A compromise solution could be to run 1-second timers in the background for (say) 1 minute before stopping them. If a user doesn't switch back to Fennec within 1 minute, they probably won't be back for a while.

I found a webpage with a setTimeout() counter. The ICS stock browser stops timers when backgrounded. Chrome Beta does not! (The timer test I found only runs for 10 seconds, so I don't know if Chrome eventually stops its timers.)
(In reply to Justin Lebar [:jlebar] from comment #14)

> I'm not sure exactly how this breakage would occur, exactly (we're of course
> going to restart the timers when Fennec launches again), but I'm much more
> concerned about silently breaking a user's phone than about breaking a
> poorly-designed webpage.

OK. Let me go the other way here. non-active (background) tabs currently clamp timers at 1 hz. Why? Why not suspend them too. They pose the same problem IMO. Hence I was treating background tabs and background app the same.

Agreed? If so, we could open a bug to add a preference to control the cllmap frequencey (1 hz by default, but 0 to suspend).

(In reply to Chris Peterson (:cpeterson) from comment #15)

> I found a webpage with a setTimeout() counter. The ICS stock browser stops
> timers when backgrounded. Chrome Beta does not! (The timer test I found only
> runs for 10 seconds, so I don't know if Chrome eventually stops its timers.)

I suspect Chrome is using the same code it uses for desktop, just like I am susgesting for Firefox.
> OK. Let me go the other way here. non-active (background) tabs currently clamp timers at 1 hz. Why? 
> Why not suspend them too.

I don't really mind if nytimes.com refreshes itself while it's in a background tab on my laptop.  In fact, I might want that.  But in contrast, I would certainly mind if nytimes.com drained my battery while firefox was "closed" on my phone.

The difference is, there's no clear way to "close" Fennec on Android, and there's no clear way to "turn off" your Android phone.

> Agreed? If so, we could open a bug to add a preference to control the cllmap frequencey (1 hz by 
> default, but 0 to suspend).

Sure, and setting it to 0 on mobile sounds good to me.
(In reply to Justin Lebar [:jlebar] from comment #17:
> The difference is, there's no clear way to "close" Fennec on Android, and
> there's no clear way to "turn off" your Android phone.

menu->quit ?
(In reply to Brad Lassey [:blassey] from comment #19)
> (In reply to Justin Lebar [:jlebar] from comment #17:
> > The difference is, there's no clear way to "close" Fennec on Android, and
> > there's no clear way to "turn off" your Android phone.
> 
> menu->quit ?

I hope we agree that this is not something users should ever have to do.
I'm confused, you said you wanted a way to "close" fennec. That's menu->quit. If you want fennec to live in the background and for web apps to continue to run, then don't do menu->quit.
(In reply to Brad Lassey [:blassey] from comment #21)
> I'm confused, you said you wanted a way to "close" fennec. That's
> menu->quit. If you want fennec to live in the background and for web apps to
> continue to run, then don't do menu->quit.

I want the following invariant to hold: If I

 1) load app X, then
 2) press the home button, then
 3) load app Y, then 
 4) use app Y for time T,

then my phone should use exactly the same amount of battery power and generate exactly the same amount of network traffic during steps (3-4) as it would if I'd skipped steps (1-2).

Users should not have to substitute menu -> quit for step (2) in order for the invariant to hold.
I disagree, I want to be able to load a web app that's going to do something, go check my email while its doing it then come back and find its done.
Why would a web app want it's timers to be clamped to 1s when it's in the background? Shouldn't the web app just be running normally, when it wanted to?
(In reply to Brad Lassey [:blassey] from comment #23)
> I disagree, I want to be able to load a web app that's going to do
> something, go check my email while its doing it then come back and find its
> done.

If you wanted to relax the invariant by adding a step in between 2 and 3:

  2a) wait V seconds for some small V, then

I'd be happy with that.
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #24)
> Why would a web app want it's timers to be clamped to 1s when it's in the
> background? Shouldn't the web app just be running normally, when it wanted
> to?

So the nytimes.com "web app" should have free reign to eat my battery and data while Fennec is in the background?  Why is this a good idea?

Do you seriously think we should tell users that they have to "menu -> quit" Fennec if they don't want Fennec to randomly suck their battery and data?  Do you seriously think that anybody will do this?
(In reply to Justin Lebar [:jlebar] from comment #26)
> (In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #24)
> > Why would a web app want it's timers to be clamped to 1s when it's in the
> > background? Shouldn't the web app just be running normally, when it wanted
> > to?
> 
> So the nytimes.com "web app" should have free reign to eat my battery and
> data while Fennec is in the background?  Why is this a good idea?
You are making the assumption that this will kill battery with no data to show that that is a real world problem.

> Do you seriously think we should tell users that they have to "menu -> quit"
> Fennec if they don't want Fennec to randomly suck their battery and data? 
> Do you seriously think that anybody will do this?
You brought up wanting to "close" fennec, I simply told you how to do it. No, I don't think users "have to" do menu->quit. I think that we want web apps to be first class citizens on mobile and to do that they need to be able to do stuff when in the background.
(In reply to Justin Lebar [:jlebar] from comment #26)
> So the nytimes.com "web app" should have free reign to eat my battery and
> data while Fennec is in the background?  Why is this a good idea?

No, I don't think that is a good idea, but isn't that what basically is decided currently? The clamping to 1s is sort of trying a middle ground, I guess?
Perhaps would a navigator.stayAliveWhileInBackground() function in combination with a doorhanger permission prompt would be a solution?
> You are making the assumption that this will kill battery with no data to show that that is a real 
> world problem.

Please see comment 14.

> You brought up wanting to "close" fennec, I simply told you how to do it.

Perhaps I wasn't clear.  I said

> The difference is, there's no clear way to "close" Fennec on Android

What I meant was, the user's expectation is that the home button "closes" Fennec, because the way to kill the process, menu -> close, is hidden.  It's not a big X at the top of the screen.

> I think that we want web apps to be first class citizens on mobile and to do that they need to be 
> able to do stuff when in the background.

Are you distinguishing between "web apps", which appear to the user to be a native app but which happen to be rendered using Gecko, and web pages?

I don't know Android's policy about allowing apps to do work in the background.  Obviously we should allow, e.g. a music apparently-native-but-actually-web app to play music in the background.

OTOH, we should not allow nytimes.com to refresh itself when Fennec is in the background.
(In reply to Justin Lebar [:jlebar] from comment #29)
> > You are making the assumption that this will kill battery with no data to show that that is a real 
> > world problem.
> 
> Please see comment 14.
Perhaps I wasn't clear. Its trivial to write a malicious page to do it, but there is no evidence that pages that people are actually visiting cause significant batter issues. Especially not with clamping to 1s.

Also, I should note that it is trivial to write a page that crashes the browser. This is not the standard we're going for here.

> 
> > You brought up wanting to "close" fennec, I simply told you how to do it.
> 
> Perhaps I wasn't clear.  I said
> 
> > The difference is, there's no clear way to "close" Fennec on Android
> 
> What I meant was, the user's expectation is that the home button "closes"
> Fennec, because the way to kill the process, menu -> close, is hidden.  It's
> not a big X at the top of the screen.

It is hard to speak for users, but at no point did I ever think that hitting the home button would close anything. It brings you to the home screen.


> 
> > I think that we want web apps to be first class citizens on mobile and to do that they need to be 
> > able to do stuff when in the background.
> 
> Are you distinguishing between "web apps", which appear to the user to be a
> native app but which happen to be rendered using Gecko, and web pages?
I see no distinction. They are one and the same.
> 
> I don't know Android's policy about allowing apps to do work in the
> background.  Obviously we should allow, e.g. a music
> apparently-native-but-actually-web app to play music in the background.
If I go to pandora in fennec to play music, then put it in the background. I want it to continue playing music. Same with a hypothetical run monitoring web page, I want it to collect data while I run and listen to pandora, both in the background.
> 
> OTOH, we should not allow nytimes.com to refresh itself when Fennec is in
> the background.
why not? We specifically have the notification API so web apps (and web pages) can get the users attention while in the background. What if the nytimes wanted to monitor a story (like a sports game, or a breaking news event) that the user had indicated interest in and alert them when there was an update.
I always thought that the pageVisibility API allowed apges to call preventDefault() when going into the background to avoid being throttled:

http://www.w3.org/TR/page-visibility/

but that's not in the spec. Personally, I think we should do something like that though.
> Perhaps I wasn't clear. Its trivial to write a malicious page to do it, but there is no evidence 
> that pages that people are actually visiting cause significant batter issues. Especially not with 
> clamping to 1s.

It's trivial to write a non-malicious page to do it, such as a news page which refreshes itself periodically.  Are you saying that we should only fix this problem once we're presented with such a page?

> If I go to pandora in fennec to play music, then put it in the background. I want it to continue 
> playing music. Same with a hypothetical run monitoring web page, I want it to collect data while I 
> run and listen to pandora, both in the background.

Pandora should request, using an API which may not exist, to stay alive while in the background.  Indeed, Pandora would need to use such an API even if we changed nothing, because Fennec may be killed by the OS at any time.

I don't have a problem with allowing pages to request to stay alive.  So long as the user approves it, that's cool.  The problem is when a page which the user believes is closed continues to use battery and bandwidth.
> The problem is when a page which the user believes is closed continues to use battery and bandwidth.

This is our fundamental disagreement I think. IMO, there is no reason for the user to think that the page is closed.
(In reply to Brad Lassey [:blassey] from comment #33)
> > The problem is when a page which the user believes is closed continues to use battery and bandwidth.
> 
> This is our fundamental disagreement I think. IMO, there is no reason for
> the user to think that the page is closed.

How often do you "close" an app on Android?  I don't even "close" Pandora -- I pause it, then press the home button.

If users aren't supposed to find menu->close, and aren't supposed to think that "home" closes Fennec, how are they supposed to express their desire that Fennec stop using CPU and bandwidth?
(In reply to Justin Lebar [:jlebar] from comment #34)
> (In reply to Brad Lassey [:blassey] from comment #33)
> > > The problem is when a page which the user believes is closed continues to use battery and bandwidth.
> > 
> > This is our fundamental disagreement I think. IMO, there is no reason for
> > the user to think that the page is closed.
> 
> How often do you "close" an app on Android?  I don't even "close" Pandora --
> I pause it, then press the home button.
So, when it comes to pandora there doesn't seem to be any expectation that hitting the home button will close it. or stop it. Why is the browser different.
> 
> If users aren't supposed to find menu->close, and aren't supposed to think
> that "home" closes Fennec, how are they supposed to express their desire
> that Fennec stop using CPU and bandwidth?

If you want a tab to stop doing stuff, close it.
Is it normal for Android applications to keep running while they are in the background? Afaik, they are all suspended when the Home button is pressed.
When they are still active in the background, like the Music Player, then an icon is shown in the Android status bar that that specific application is still running.
Your process stays a live when you go to the background. You can continue to do whatever you want. Once in the background you're more likely to be killed in a low memory situation, but that is increasingly unlikely on modern devices.

Having an icon in the task bar is entirely optional is no indication of whether anything is happening or not.
It seems we have wildly different conceptions of what it's like to use an Android phone.  I'm pretty confused by this, to be honest.  In my view, Android got rid of the distinction between "running" and "backgrounded" apps, from the user's point of view.  You just "go away" from the app, and you trust that it's not going to continue wearing down your battery or silently using data without your knowledge.

It sounds like that's not your experience, which I find perplexing.  Perhaps you could elaborate, with examples of how you use your phone.

> If you want a tab to stop doing stuff, close it.

The thing is, a user will have no indication that a tab is doing stuff.  Fennec is in the background, and gives no indication that it's running.  And moreover the tab that's eating up battery and/or data may not even be the foreground tab, and may not give any indication that it's doing anything.

Why is it the user's job to figure all this out?  Fennec can be killed at any time, so if a page *wants* to run in the background, to play music or whatever, it would have to ask, otherwise, it'll die when Fennec dies.  So we have to have an API for requesting background tasks anyway.  Given that, why are we allowing tabs which don't ask to run in the background to run in the background?
(In reply to Chris Peterson (:cpeterson) from comment #15)
> I found a webpage with a setTimeout() counter. The ICS stock browser stops
> timers when backgrounded. Chrome Beta does not! (The timer test I found only
> runs for 10 seconds, so I don't know if Chrome eventually stops its timers.)

The timers of background tabs are suspended in Chrome Beta on Android, though.
Would it be possible to have this as a preference that the user can set (via an addon or something?)
(In reply to Naoki Hirata :nhirata from comment #40)
> Would it be possible to have this as a preference that the user can set (via
> an addon or something?)

It already is. See bug 736602 and "dom.min_background_timeout_value"
tracking-fennec: ? → -
blocking-fennec1.0: ? → -
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: