- From: Xidorn Quan <notifications@github.com>
- Date: Thu, 01 Feb 2018 16:16:22 -0800
- To: whatwg/fullscreen <fullscreen@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fullscreen/pull/102/review/93484188@github.com>
upsuper commented on this pull request. > <li><p>Let <var>exitDocs</var> be the result of <a lt="collect documents to unfullscreen">collecting documents to unfullscreen</a> given - <var>doc</var>. + <var>pendingDoc</var>. > To fully exit fullscreen couldn't fix this case I'm afraid, some bookkeeping would still be needed to remember that B had a fullscreen element and should get a fullscreenchange event after the resize. Not necessarily? I think we can change `fully exit fullscreen` to this: 1. Let topLevelDoc be document’s top-level browsing context’s active document. 2. If topLevelDoc ’s fullscreen element is null, terminate these steps. 3. Let docs be an ordered set consisting of topLevelDoc’s descendant browsing contexts' active documents whose fullscreen element is non-null, in tree order. 4. For each doc in docs: * Append (fullscreenchange, doc's fullscreen element) to doc’s list of pending fullscreen events. * Unfullscreen doc. 5. Run the following step in parallel. 6. Resize topLevelDoc’s viewport to its "normal" dimensions. Then we just need to call `fully exit fullscreen` in the removing steps when fullscreen element is found in it. Since this `fully exit fullscreen` doesn't involve any asynchronous operation on top layer (either read or write), it can be safely used as the last resort cleanup for everything now. And this procedure should be more robust that it doesn't need much change however fullscreen works. (e.g. with or without hierarchy restriction) > If we were to decide up front how to manipulate the top layer of each document, and in the async part are able to somehow handle the differences from what we expected the top layers to look like, It's not clear to me how it would look like... Everything I can think based on this feels overcomplicated... > Or should we look for something non-clever that often does the right thing and is known to be broken if you do something too strange? I don't think we should leave an active document being in a broken state... Edge cases can happen unintentionally (e.g. in some race condition), and we should handle that gracefully as much as possible... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fullscreen/pull/102#discussion_r165527768
Received on Friday, 2 February 2018 00:16:48 UTC