Page Lifecycle

[smaug----]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Page Lifecycle
• Specification or proposal URL: https://wicg.github.io/page-lifecycle/
• Explainer: https://github.com/WICG/page-lifecycle
• Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480376

Other information

The proposal needs still reviewing. And need to be careful whether it works well enough with bfcache (it is a Google proposal and blink doesn't have bfcache).

[domenic]

Hey folks, @rakina is working on improving HTML's bfcache specification, and one of the things that would be good is to clarify the interaction with page lifecycle. (E.g., integrating https://wicg.github.io/page-lifecycle/#html-bfcache-dfn with some of the discussion in whatwg/html#5879 (comment).)

We're wondering where Page Lifecycle sits on the WHATWG "multi-implementer interest" spectrum, given Mozilla's previous helpful reviews, but also this issue being open, and there being no non-Chrome implementations. I can imagine three end states:

• Page Lifecycle continues to monkeypatch HTML, including the bfcache steps. So, we'd improve HTML's infrastructure per Back-forward cache: Specifying ineligibility? whatwg/html#5879 (comment) , but then have Page Lifecycle continue monkeypatching HTML; there'd be no direct callout from HTML to Page Lifecycle.
• HTML calls out to Page Lifecycle at various points, basically by incorporating the monkeypatches in https://wicg.github.io/page-lifecycle/#mod into HTML. Perhaps we'd apply a softer version of "multi-implementer interest" to these sort of callouts.
• We fold Page Lifecycle entirely into HTML (and Service Workers).

Figuring out what path we're going to take here would benefit a lot from figuring out Mozilla's standards-position on Page Lifecycle, so we'd love your thoughts!

[annevk]

@smaug---- and I discussed this a bit and overall this seems reasonable. Integration with HTML seems good, especially with regards to constraining the "final callback". (I skimmed the explainer, but I didn't see what would happen with the various dialogs pages can spawn and such. And there might be more APIs we want to limit during freezing/teardown, e.g., notifications.)

We would like to hear from @rniwa and others at Apple as they had concerns in the past.

[rniwa]

Our biggest concern was "discard" event which was meant to be dispatched right before we throw away a web page. It looks like that got replaced by "freeze" event, which gets dispatched right before we "freeze" a background tab. We'd have to think about implications of that approach. Running more scripts just as we try to "freeze" a process may be problematic as well.

[martinthomson]

@domenic, I see that you have done some housekeeping on the spec, but it otherwise hasn't moved in a few years. Is this still a going concern, or has it moved into back-forward specification work on HTML?

[domenic]

This is still a going concern. Essentially Chrome on Android is exposing a few extra APIs for background-tab freezing, such as lifecycleState or the freeze event. I've also heard we might be looking into expanding this onto desktop. From what I understand having these APIs available was pretty important for being able to do background tab freezing since otherwise websites could end up broken, with no ability to fix themselves.

I believe other browsers might have some sort of background-tab freezing, at least on mobile, but do not expose APIs to developers for it. We're currently keeping the spec in a holding pattern, trying to do a reasonable amount of maintenance, so that if other browsers do want to expose such APIs for their functionality, we have laid out a reasonable path and can use the spec and its repo as a collaboration point.

/cc @shaseley @chhamilton who are closer to the project and may be able to expand or correct me.

[shaseley]

+1 to what @domenic said. We'll also be looking at discarding again soon, and we'll evaluate if any additional API surface is needed, but the initial thinking is that wasDiscarded is probably sufficient.