Fullscreen request from a subframe for a main frame user gesture |
|||||
Issue descriptionWhen testing our UserActivation v2 with Fullscreen, we discovered the following test which seems to allow a fullscreen request from a subframe after a main frame user gesture: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/fullscreen/exit-full-screen-iframe.html Note that manually testing the page works perfectly; only the eventSender-based one is flawed because the keyboard event is sent to the root frame. I doubt this is intentional. If I am correct, this is a general bug for our current implementation of user gestures: UserGestureIndicator state is "global" for renderer, so any API can be called from a subframe even when user gestures happened on a different (same-origin) frame. In v2, the above test fails, yayy!
,
Nov 15 2017
The old intended behavior should have blocked this though, right? There isn't any situation where activating only the main frame would allow a subframe to go fullscreen? (At least without some kind of gesture delegation?) I suspect this is a bug fix, but if you think we need a counter for the behavior change anyway, I'm sure we could add one.
,
Nov 15 2017
We have 3 failing tests in fullscreen/, for the exact same reason. Here are 6 (=2*3) questions to foolip@ to understand the expectations, the answers are not obvious to me from the spec, may be because I am missing some implicit details around "browsing context". Suppose we have frame P containing a child frame C, and P has just seen a user activation. When they have (A) the same origin, and (B) different origins, can: (1) P make an element in C fullscreen? (2) C make an element in C fullscreen? (3) C make an element in P fullscreen?
,
Nov 21 2017
https://fullscreen.spec.whatwg.org/#allowed-to-request-fullscreen depends on https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation which is known to be a bit wrong, so what the answers that come from reading that can't be trusted entirely. But, it defines things in terms of tasks, and "The task in which the algorithm is running was queued" with a time limit, so I'd say that any short chain of setTimeout or postMessage same- or cross-origin should work per the current spec. So, "P make an element in C fullscreen" by reaching into C directly or via postMessage, but C can only do things in a task that connects back to the original task in P. In other words, a setTimeout loop in C shouldn't succeed around the time of the click on P.
,
Nov 21 2017
To make the (A) vs. (B) answer explicit, I can spot no explicit distinguish made between them as HTML is currently written. As for what would make sense ignoring the spec, I think that all patterns that work for cross-origin should also work for same-origin, and that any same-origin patterns that don't work for cross-origin don't work because of some other existing limitation, not because of explicit cross-origin logic for user activation. Such a limitation would be the inability to access the iframe.contentDocument for a cross-origin iframe, making it impossible to call requestFullscreen() inside that iframe synchronously from a click event in the parent frame.
,
Nov 21 2017
Thanks, I will fix the tests according to #c4 (i.e. as per current activation spec). Re #c5: This makes sense, thanks. I still have one follow-up question from the perspective of our new frame-based user activation model (so please ignore current activation spec): --- In the same origin case, if the parent frame's click handler calls iframeElem.contentDocument.documentElement.webkitRequestFullScreen(), should the call succeed? I thought the answer should be "yes" but then the "context" in the current FullScreen spec should include an "execution context" (who is making the call) in addition to the "context object" we have today. https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen Wdyt?
,
Nov 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/fdd52df96081dcb00b3fdf6ccb6726f60b49173c commit fdd52df96081dcb00b3fdf6ccb6726f60b49173c Author: Mustaq Ahmed <mustaq@google.com> Date: Thu Nov 23 15:43:24 2017 Fix fullscreen layout-test scripts to match manual tests. The manual parts of these tests ask for mouse clicks in subframes. But the scripts used to send key events to main frame instead. Bug: 784999 Change-Id: I84e72334c78cc6af981c4fb6d51a32bba6554a4c Reviewed-on: https://chromium-review.googlesource.com/786298 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/heads/master@{#518946} [modify] https://crrev.com/fdd52df96081dcb00b3fdf6ccb6726f60b49173c/third_party/WebKit/LayoutTests/fullscreen/exit-full-screen-iframe.html [modify] https://crrev.com/fdd52df96081dcb00b3fdf6ccb6726f60b49173c/third_party/WebKit/LayoutTests/fullscreen/full-screen-iframe-allowed.html [modify] https://crrev.com/fdd52df96081dcb00b3fdf6ccb6726f60b49173c/third_party/WebKit/LayoutTests/fullscreen/full-screen-iframe-not-allowed.html [modify] https://crrev.com/fdd52df96081dcb00b3fdf6ccb6726f60b49173c/third_party/WebKit/LayoutTests/fullscreen/full-screen-iframe-ua-style.html [add] https://crrev.com/fdd52df96081dcb00b3fdf6ccb6726f60b49173c/third_party/WebKit/LayoutTests/fullscreen/resources/inner-video.html [modify] https://crrev.com/fdd52df96081dcb00b3fdf6ccb6726f60b49173c/third_party/WebKit/LayoutTests/fullscreen/resources/inner.html
,
Nov 23 2017
,
Nov 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c32e5f1c178f70f950ab26ff5c08bad4c5c778f7 commit c32e5f1c178f70f950ab26ff5c08bad4c5c778f7 Author: Mustaq Ahmed <mustaq@google.com> Date: Fri Nov 24 17:08:06 2017 Fixed click coordinates in one layout test. Bug: 784999 Change-Id: Ief9fe76301c214721584c8e51bd9f2225f7e0a3c Reviewed-on: https://chromium-review.googlesource.com/788131 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/heads/master@{#519137} [modify] https://crrev.com/c32e5f1c178f70f950ab26ff5c08bad4c5c778f7/third_party/WebKit/LayoutTests/fullscreen/model/fully-exit-fullscreen-nested-iframe.html [modify] https://crrev.com/c32e5f1c178f70f950ab26ff5c08bad4c5c778f7/third_party/WebKit/LayoutTests/fullscreen/trusted-click.js
,
Nov 24 2017
The only test that remain is fullscreen/api/element-request-fullscreen-two-iframes.html, see Issue 627792 . We won't fix this test until we have the new activation model in a shippable state.
,
Nov 29 2017
,
Jan 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/69a828594a7b4e83a35eaf0b4be417434880b588 commit 69a828594a7b4e83a35eaf0b4be417434880b588 Author: Mustaq Ahmed <mustaq@google.com> Date: Mon Jan 15 15:50:10 2018 Fixed the click coordinate in a fullscreen layouttest. Bug: 784999 , 627792 Change-Id: I120d97f3d9b248bfe3cb22f1ff89b43101fc17b4 Reviewed-on: https://chromium-review.googlesource.com/861748 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Cr-Commit-Position: refs/heads/master@{#529288} [modify] https://crrev.com/69a828594a7b4e83a35eaf0b4be417434880b588/third_party/WebKit/LayoutTests/fullscreen/api/element-request-fullscreen-two-iframes.html
,
Jan 16 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by foolip@chromium.org
, Nov 15 2017