- From: Xidorn Quan <web-platform-tests-notifications@w3.org>
- Date: Wed, 30 Nov 2016 00:57:19 GMT
- To: public-web-platform-tests-notifications@w3.org
I think the current behavior in document-exit-fullscreen-vs-request-manual.html is expected. What happens there would probably be: * `child.requestFullscreen();` -> sync check sets `resize` to false, and queue a task to the next frame * `document.exitFullscreen();` -> sync check sets `resize` to true, and start async resize * `child.requestFullscreen();` -> sync check sets `resize` to false, and queue a task to the next frame If the resize is done later than the next frame, then the two `requestFullscreen` would does nothing. If the resize is done earlier than the next frame, then the two `requestFullscreen` would end up trying to change the document state without the viewport being fullscreen, which is undesired. We may want to add another check that if the viewport is not in fullscreen, terminate the steps (with rejecting the promise and probably a `fullscreenerror` event?) Having said this, it seems to me it would pretty much depend on the timing of resize, which, AFAICT, is platform-dependent. Firefox may already have different behavior on different platforms, especially Linux. Given this, I suggest we say explicitly that the timing of resize is intentionally undefined (or impl-dependent), and then avoid testing this kind of edge cases in wpt. I think any web page relying on behavior of conflicting resize direction should already been broken enough that isn't worth worrying about. View on GitHub: https://github.com/w3c/web-platform-tests/pull/4250#issuecomment-263750259
Received on Wednesday, 30 November 2016 00:57:32 UTC