"App-state" API, so that content knows when it becomes hidden etc.

RESOLVED DUPLICATE of bug 702880

Status

()

defect
RESOLVED DUPLICATE of bug 702880
8 years ago
2 months ago

People

(Reporter: cjones, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sec-assigned:curtisk:749342])

Note from Paul:

Especially important on mobile devices, browsers can halt the execution temporarily for incoming calls, sleep mode or simply quick exiting the app. Like for applications, web apps need a small time window to stop running processes in this case. This is especially relevant when working with Web Workers and Web Sockets, which turn out to be rather unforgiving when not closed and then later on resumed.  - can we hook into Page Visibility API?

Addendum:

I'm not familiar with the Page Visibility API, but for example with bug 673352, a WebGL game continues happily chomping away at CPU, GPU, and sound device resources when Firefox Mobile is "minimized".  AFAIK there's no way for the page to listen for a "minimized" or "inactive" event, so there's really nothing the author can do.  That stinks.  Attempting to automatically block every expensive API a page might use in the background, like the setTimeout throttling we do, sounds like a slippery slope to me.  Instead, we should add an API like the android app-state notifications so that apps can throttle themselves, and then in the UA expose resource-usage info so that users can blame web apps not using these APIs when the users' device batteries die too fast.
> a WebGL game continues happily chomping away at CPU, GPU, and sound device
> resources when Firefox Mobile is "minimized".

Does that make the docshell inactive?

If so, the effect right now is that we will throttle timeouts to 1Hz and do exponential backoff on the refresh driver.  If the page is doing its animations using requestAnimationFrame it will be backed off on very quickly.  If the page is using setTimeout/setInterval, those will only only run once per second.

But yes, Page Visibility solves this use case, I believe.  It exposes the current visibility and fires a visibilitychange event when the visibility changes, so that apps that want to play nice can do so easily.
(In reply to comment #1)
> > a WebGL game continues happily chomping away at CPU, GPU, and sound device
> > resources when Firefox Mobile is "minimized".
> 
> Does that make the docshell inactive?

Good question.  If it doesn't, it should!

> If so, the effect right now is that we will throttle timeouts to 1Hz and do
> exponential backoff on the refresh driver.  If the page is doing its
> animations using requestAnimationFrame it will be backed off on very
> quickly.  If the page is using setTimeout/setInterval, those will only only
> run once per second.

Does docshell inactivity affect audio playback?
> If it doesn't, it should!

This is apparently bug 668271.  And no, it does not at the moment.

> Does docshell inactivity affect audio playback?

Only insofar as it throttles setTimeout and the refresh driver.  You can keep playing audio if you buffer up 1000ms of audio every time your callback happens.

Throttling audio playback in general for inactive docshells is no good, because in some cases people really do want to put their mp3 player website in a background tab.
(In reply to comment #3)
> Throttling audio playback in general for inactive docshells is no good,
> because in some cases people really do want to put their mp3 player website
> in a background tab.

Indeed.  I wonder if visibility-aware apps like my radio should get their background throttle turned off (say once they hook up to "visibilitychange"), too, so they don't have to jump through hoops for good playback.  Something to think about once we have a WIP I guess.
On your typical website, I would expect that the site loads something like jquery which hooks into visibilitychange as a matter of course because it wants to be smart about its internal animation management... and that tells you absolutely nothing about whether the site code itself is visibility-aware.  :(
I would be fine, for "trusted" apps with just exposing a non-throttled callback of some sort, by the way.  It could even be setTimeout...
We don't throttle setTimeout for Workers of background docshells, right?  So I guess an app that really cared enough could emulate our timer-thread architecture...
> We don't throttle setTimeout for Workers of background docshells, right? 

"Not yet".... ;)

Comment 10

8 years ago
I agree that throttling isn't enough unfortately. Take web sockets as an example. When the browser tab is hidden or disabled because of an incoming phone call or whatever, you definitely will want to cap the socket.

I like throttling in general, but I don't think it would hurt to have a more explicit API (like page visibility, but for other changes) as well.
Hopefully the page visibility API will help us here yes.

We also have the "PageHide" and "PageShow" events which we currently fire when putting a page in the BF cache and when reviving it. We could potentially fire those at for example apps that are being minimized (or have been minimized for a while). It would of course be up to the page to do something useful with this, which unfortunately most would not :(

Comment 12

8 years ago
(In reply to comment #11)
> Hopefully the page visibility API will help us here yes.
> 
> We also have the "PageHide" and "PageShow" events which we currently fire
> when putting a page in the BF cache and when reviving it. We could
> potentially fire those at for example apps that are being minimized (or have
> been minimized for a while). It would of course be up to the page to do
> something useful with this, which unfortunately most would not :(

We definitely would :)
pagehide/show are pretty specific to session history, and they fire also during
page load/unload, so I wouldn't reuse those events.

Comment 14

8 years ago
(In reply to comment #13)
> pagehide/show are pretty specific to session history, and they fire also
> during
> page load/unload, so I wouldn't reuse those events.

Good point. It's also not the right semantic for a "engine on hold". On mobile Safari for instance, if you pan the page, it halts the browser thread until you release the touch again. The page is technically still visible at this point, but frozen.
(In reply to comment #11)
> It would of course be up to the page to do
> something useful with this, which unfortunately most would not :(

If we expose enough resource-usage data to users to let them point fingers at offending apps when their battery drains, then we can use the free market to help correct these problems.

Comment 16

8 years ago
Isn't the onFocus attribute on the body element set to false when the browser is minimized in a mobile browser (Android, iOS, Windows Phone)?  If not, would that, with the addition of pause/resume events, be helpful?

Comment 17

8 years ago
Don't want to make things too noisey but there is some prior art w/ PhoneGap to be considered here: http://docs.phonegap.com/phonegap_events_events.md.html
Definitely.  Thanks for the link.
assigned to me for sec action so we can schedule a review
Whiteboard: [secr:curtisk]
Whiteboard: [secr:curtisk] → [sec-assigned:curtisk:749342]
This bug is a bit all over the place so I might miss something. But if this bug is just about the visibility API then that's happening in bug 715784.

If this bug is about more things, please feel free to reopen or file separate bugs and mention them here.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 702880
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.