Received: by 10.68.125.233 with SMTP id mt9mr3888127pbb.5.1333123428239;
        Fri, 30 Mar 2012 09:03:48 -0700 (PDT)
Path: z9ni19176pbe.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: Brad Lassey <b...@lassey.us>
Newsgroups: mozilla.dev.platform
Subject: Behavior of background tabs and webapps
Date: Fri, 30 Mar 2012 09:03:47 -0700 (PDT)
Organization: http://groups.google.com
Lines: 82
Message-ID: <2531660.327.1333123427669.JavaMail.geo-discussion-forums@vbbp15>
NNTP-Posting-Host: 71.232.159.36
Mime-Version: 1.0
X-Trace: posting.google.com 1333123427 29629 127.0.0.1 (30 Mar 2012 16:03:47 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 30 Mar 2012 16:03:47 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.232.159.36;
 posting-account=tzsCaAoAAADCtby-MjW5P13r5TakQSTV
User-Agent: G2/1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Recently several bugs have been filed which boil down to weighing the funct=
ionality of background tabs in Firefox for Android against potential batter=
y life issues that functionality brings. Since this sort of balancing act i=
s also of interest people working on B2G and WebAPIs teams we had a call to=
 talk through some of the implications. Now that we've fleshed out the disc=
ussion, we'd like to take it to the news groups. Hence this post.

First the question of what constitutes a background tab or web app was deba=
ted (I'm just going to call them background tabs going forward). At first d=
efining background tabs as any tab without focus was assumed. Then Chris Jo=
nes pointed out that it will be possible in the future to interact with 2 o=
r more windows simultaneously on a big enough multitouch screen. Given that=
, we settled on defining background tabs as any tab which is not currently =
visible. The question was then raised about hidden iframes in otherwise vis=
ible tabs. It is assumed that any iframe in a visible tab would be consider=
ed visible and therefore foreground.

Then to frame the discussion we brainstormed about some scenarios which we =
would specifically like to enable for background tabs:
 * Listening to Pandora in the background
 * run/jog tracking app
 * gmail/twitter synching in background
 * skype receiving phone calls
 * skype remaining on call when switching to another app
 * sms app receiving messages
 * phone app receiving phone calls
 * apps that need to be opened from startup
 * webapps that use WebSockets or DOMRemoteEvents to get push messages and =
show notifications

During this brainstorming session we identified a scenario that we could no=
t agree on and that is, if a user is playing a game and switches to check t=
heir email should the game continue to play (i.e. character continues to mo=
ve through the world, music plays etc.). It is without doubt that the game =
should be able to detect this with existing APIs and pause itself for the s=
ake of a good user experience. The question is whether the platform should =
enforce that behavior. This comes down to "the iOS model" vs. "the desktop =
model" and we determined that gecko as a platform should support both and t=
he front end (Firefox for Android, B2G, Joe's awesome app engine) should be=
 what makes that sort of policy decision.

Specifically, the things that we want to consider throttling or stopping wh=
en a tab is in the background are timer events, sensor events, video decodi=
ng and WebGL. There may be others, and we should identify them.=20

Timer events are on the list because they cause the tab to do work that isn=
't high priority for the user at the time. Sensor events are on the list fo=
r similar reasons, but in addition to that require the device to power sens=
ors (gps, accelerometer, proximity sensor etc.) unnecessarily (perhaps?).

Video decoding and WebGL are on the list because the user can't see the pro=
duct of these activities if the tab is not visible. Specifically, in the ca=
se of video decoding, audio should still be played, to support the case of =
listening to a video lecture or meeting which doing other things. Video sho=
uld probably still be decoded if the page is reading the decoded data throu=
gh js.

Finally, to frame the discussion we thought it would be most useful to defi=
ne a set of states which a tab could be in. Up to this point we've only tho=
ugh about foreground and background, but given that we want to be able to t=
hrottle, pause or even kill background tabs to save batter and memory we ca=
me up with the following set of states and their definitions:
states:
foreground -> background -> paused -> killed -> closed

foreground: currently active tab or equivalent
background: current non-active tab behavior
paused: bfcache=20
killed: session data saved, but no longer loaded
closed: explicitly quit by user, no session data saved

Closed and killed may in the end be the same thing, with the only differenc=
e being a front end policy decision on whether to restore the session when =
reviving.

Assuming no one disagrees strongly with the basics we've laid out (big assu=
mption, I know), the discussion we'd like to have on the news groups is wha=
t should be throttled and by how much in the background state. There is als=
o a good discussion to be had about what should cause a tab to go into the =
paused or killed state, but I'd like to specifically exclude that from this=
 thread as it should be a front-end policy decision which the gecko platfor=
m will need to support.