How are unloaded tabs represented?

[jakearchibald]

Mobile browsers put tabs into an "asleep" state to save memory & battery as needed. If you focus the tab later, the page is reloaded, but may regain some state within form elements.

This behaviour is completely unspecified, but I think we should put some guidance in the SW spec for these pages.

Specifically:

• Do asleep tabs prevent a SW moving from "waiting" to "active"?
• Do asleep tabs show up in clients.getAll()?

[jakearchibald]

My take:

I don't think asleep tabs should have an effect on the lifecycle within a registration. These tabs are going to reload anyway, having them reload with an updated version seems fine. Given that tab-management is pretty much a lost art in Android L, you'd very easily end up with old forgotten tabs preventing updates becoming active.

Having asleep tabs show up in clients.getAll() is somewhat desirable, as following a push message you can focus one of these existing tabs rather than opening a new one. However, given that tab management isn't really a thing anymore in Android L, maybe it doesn't matter if you open a new window vs focusing an asleep one. I don't think there's a performance benefit.

(I realise this is a bit Android-specific, so interested in hearing from other vendors)

[wanderview]

I believe the goal on fxos is for tabs to get killed on memory pressure and relaunch with some kind of persisted state. I think treating waking asleep tabs as a reload would work for that case as well.

[johnmellor]

However, given that tab management isn't really a thing anymore in Android L, maybe it doesn't matter if you open a new window vs focusing an asleep one.

Even with Chrome on Android L, users still don't expect to see duplicate entries in their Recents (they can also disable Chrome Settings > "Merge tabs and apps" to go back to a traditional tab switcher, or use other browsers). So it's still better if webapps can reuse existing tabs, including asleep ones.

Having asleep tabs show up in clients.getAll() is somewhat desirable

How about adding an includeAsleep option to matchAll?

The expectation would be that if you includeAsleep, you shouldn't postMessage to all the clients (as that is likely to cause excessive RAM usage, as well as CPU churn from reloading them all); I'm not sure if/how that API should enforce that.

See also some earlier discussion on #414 (comment)

[jakearchibald]

How about we add a note in the spec to allow the browser to resurrect an asleep tab with a matching url, if openWindow(url) is called?

That avoids the postMessage issue, and means asleep tabs don't need to be fully spec'd.

[johnmellor]

Two issues with that:

1. The browser would presumably only overwrite tabs with exact URL matches, but webapps frequently change URL via history.pushState or location.hash. It's better to let the webapp decide whether to reuse tabs (e.g. maybe it's ok to reuse /sent to show /inbox).
2. Browsers like to do nice things like restoring form data when resurrecting an asleep tab. If they just overwrite the asleep tab, there may be some data loss; though I guess they could avoid overwriting if the user modified form data.

[jakearchibald]

Yeah, you're right. An option on clients.matchAll is the right way forward.

postMessage to asleep clients should fail I think, unless focus is called first.

[johnmellor]

Sounds good. Can we make Client.postMessage return a Promise instead of void, so we can communicate failure?

[jakearchibald]

We should. Noted in #609 (comment)

[johnmellor]

Naming bikeshed: asleep? unloaded? evicted? frozen?

[jakearchibald]

Unloaded & evicted correctly suggest it's not simply suspended

On Tue, 24 Feb 2015 17:46 John Mellor notifications@github.com wrote:

Naming bikeshed: asleep? unloaded? evicted? frozen?

—
Reply to this email directly or view it on GitHub
#626 (comment)
.

[jakearchibald]

'unloaded' would clash with the back/forward cache definition. Can't think of anything better than 'evicted'.

[jakearchibald]

If the 'evicted' tab had child clients (workers, iframes), would these still exist but in an evicted state? This is getting messy :(

[johnmellor]

To avoid having to standardize browsers' varying heuristics for restoring evicted tabs (e.g. restoring scroll/zoom and form data), I was thinking it would be simplest if calling focus() on an evicted tab just replaces that tab with an ordinary page load of its last known URL (making no attempt to restore state).

So no, only the top-level frame would have an evicted WindowClient.