- From: Travis Leithead <notifications@github.com>
- Date: Fri, 19 Jan 2018 23:48:46 +0000 (UTC)
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/205/359121205@github.com>
A most excellent set of docs! CC-ing @toddreifsteck since he participated in much of this review, and is in contact with the authors... Some feedback/questions: 1. Hmm... how does pagehide fire after transitioning to the STOPPED state? Aren't you CPU-starved at that point? 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). 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? 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?) 5. What happens when one of the callbacks might hang (not returning control)? Should this situation be conveyed (similar to crash flag noted earlier). Some nits: * In the table: `pagevisibility` should be [`visibilitystate`](http://www.w3.org/TR/page-visibility-2/#visibilitystate-attribute) (for the state) or [`visibilitychange`](http://www.w3.org/TR/page-visibility-2/#onvisiblitychange-event-handler) for the event :-) It was a little unclear which you mean--I originally assumed the state, but later think you meant the event. * "onpagevisibilitychange" should be "onvisibilitychange" * API sketch: not necessary to have separate interfaces for FreezeEvent and ResumeEvent, since they provide the same state. :-) -- 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-359121205
Received on Friday, 19 January 2018 23:49:20 UTC