Re: [w3ctag/design-reviews] Review request: Web Lifecycle for system initiated Discarding & Stopping (#205)

Major apologies for the delay, I somehow totally missed that this round of review has happened.
(I discussed these points with @toddreifsteck offline already)

> 1. Hmm... how does pagehide fire after transitioning to the STOPPED state? Aren't you CPU-starved at that point?

It is NOT that pagehide is fired after STOPPED -- but rather that onfreeze is fired on the way to BFCACHE. If the page is moving to bfcache (user navigation), both onfreeze and pagehide will fire. Suggestions for how to make that clear in the diagram are very welcome!

> 2. State model doesn't account for crashes, except to say that probably all state transitions are skipped... on reload should wasDiscarded be set to true? Same if a site crashes during a lifecycle callback? Might be nice to provide a bit of data that they crashed (vs. were discarded).

That is indeed the intention to set the bit when possible - even for crashes / unexpected termination cases (eg. user undoes tab close). We want to set wasDiscared for instance, when the renderer crashes however it's not possible to provide this bit in all cases eg. if the browser process itself crashes.

> 3. Consider: two site instances, both DISCARDED, when one gets re-loaded, how does the site logic know which state to resume (assuming one site instance didn't overwrite the other's data)? (Might need a GUID or some unique identifier to distinguish state? Is this a problem that can be solved in the API, or is it the web author's responsibility to handle?

Great point, this is captured here https://github.com/WICG/web-lifecycle/issues/4 and https://github.com/whatwg/html/issues/3378
The plan is to expose clientId and lastClientId on Document. 
clientId is the environment id that is currently only available on the service worker.

> 4. Consider: two frames, same domain (running on the same HTML5 event loop), if one is STOPPED, must the event loop be able to distinguish which contexts are stopped vs. not? Same question for which Render steps become optional.
Does STOPPED mean no more processing of the event loop (for all related browsing contexts?)

IIUC the case you mean is multiple tabs  -- with their own top level pages on the same origin -- sharing the renderer process and event loop? Is that right?
If so -- then one (meta) issue is that the HTML spec is disconnected from our (and likely other browsers too?) implementation. In our implementation we have page-level and frame-schedulers in addition to renderer-level scheduler. So it is not true that they are "sharing the event loop" per se. And yes there is a need to distinguish between which contexts are stopped.
Please advise on how to clarify this -- should we update the HTML spec to match the reality of implementations?
\cc @domenic 

> 5. What happens when one of the callbacks might hang (not returning control)? Should this situation be conveyed (similar to crash flag noted earlier).

The callbacks have an upper time-limit -- once the time-limit has reached the browser has two options:
a. bail and discard the tab (and tear down the page) - since freezing has failed and the page could be in an inconsistent state.
b. "pause execution" -- i.e. suspend JS without tearing down the page.
There are tradeoffs and we are currently investigating option b.) with option a.) as the fallback.






-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/205#issuecomment-373526459