Sandboxed iframes shouldn't be able to block vertical scrolling by default |
|||||||||||||||||
Issue descriptionOne way an iframe may interfere with the user experience is by blocking scrolling (possibly even getting the user trapped if the frame is big enough). There should be some mechanism to avoid this when desired. ojan, esprehn, flackr and I chatted about this in the context of https://docs.google.com/document/d/1oF1T3O7_E4t1PYHV6gyCwHxOi3ystm0eSL5xZu7nvOg/edit# and thought that sandboxed iframes probably shouldn't allow blocking of vertical touch scrolling by default. It's not uncommon to have some horizontal drag UI (eg. swipe through a carousel) and most scrolling is vertical, so we think it's best to keep this limited to vertical scrolling. Then there could be a "allow-scrolling" option which re-enables this. Or if necessary for compatibility, it could be strictly opt-out ("disallow-vertical-scrolling"). If we're going to do this for touch, there's probably no reason not to treat wheel the same (although with mouse you usually have the escape hatch of dragging a scrollbar). This seems lower priority though (it's also rarer to have an iframe that can fill the screen on desktop). This could be implemented by: - In blink, when a touch or wheel event is sent to a frame with this enabled: - If the event is a touchstart - set cancelable=false - If the touchstart generates a setTouchAction IPC, set the PanY bit (to ensure touch-action can't be used to disable vertical scrolling) - If the event is the first touchmove, check direction of motion from touchstart and if vertical set cancelable=false - Note that the GR in the browser process already knows this, we could plumb a "start of vertical scroll" bit, or we could just have blink track this. - If the event is a wheel event with abs(deltaY) > abs(deltaX), set cancelab=false Note that it's tempting to explore using this for scroll performance benefits (similar to making touch listeners in sandboxed iframes passive), but that's not the goal of this bug. My hunch is that it wouldn't be a huge win - starting scrolls on top of a sandboxed iframe is probably quite rare today (though maybe we should measure). It's also tempting to consider applying this policy to all cross-origin iframes by default, but I'm fairly sure that would be too breaking (cross-origin iframes are used to compose applications in all sorts of ways - eg. jsbin's output panel). mkwst, what do you think? Something we could explore adding to the sandboxed iframe spec?
,
Jul 1 2016
mkwst@ WDYT?
,
Jul 26 2016
Poke. Should we explore this this quarter?
,
Aug 2 2016
IIRC Mike told me in person that this seemed reasonable to him. Maybe input-dev would be the right team to own it though?
,
Aug 9 2016
Will talk to ads network to get a sense of their appetite for sandboxed iframes
,
Aug 16 2016
,
Apr 5 2017
Switching ownership to Ani.
,
Sep 12 2017
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues. We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate. For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit For any questions, please contact owencm, sshruthi, larforge
,
Oct 12 2017
mfomitchev@ says he was recently annoyed by an add that did this (presumably canceled the touchstart to suppress scrolling, and activated on touchend).
,
Nov 21 2017
,
Nov 27 2017
Discussed more here: https://docs.google.com/document/d/1oF1T3O7_E4t1PYHV6gyCwHxOi3ystm0eSL5xZu7nvOg/edit?disco=AAAAAuAPym4 Perhaps we should start by adding an opt-in feature policy for disabling this? Then we could later explore changing the default in some cases.
,
Feb 9 2018
Plan is to add a feature policy for disabling this behaviour.
,
Feb 16 2018
Thanks for working on this Ehsan! So is the plan still to disable by default in sandboxed iframes, and then allow an opt-in via feature policy? I really like changing the default for sandboxed iframes and I suspect we can get away with it from a compat perspective, but I think there is perhaps also a need to opt-out in non-sandboxed frames. The alternative is to add a feature policy to explicitly disable the ability to block vertical scroll in iframes, and then have sandboxed iframes enable this policy by default unless there is a corresponding 'sandbox' attribute saying not to.
,
Feb 16 2018
,
Apr 9 2018
,
Apr 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/17b6ae06b685758f117ece8f123b513f39d2d942 commit 17b6ae06b685758f117ece8f123b513f39d2d942 Author: Ehsan Karamad <ekaramad@chromium.org> Date: Thu Apr 12 17:32:51 2018 Introduce Feature Policy: vertical-scroll (bare feature) This CL introduces the bare feature. 'vertical-scroll' intends to block specific sandboxed frames (which do not have the feature enabled) from interfering with user's vertical scrolling in the page. The details are explained in the document: https://docs.google.com/document/d/1qiWelnMlsOHuT_CQ0Zm_qEAf54HS5DhoIvEDHBlfqps/edit?usp=sharing The actual logic for blocking such frames will land in follow-up CLs. Bug: 611982 Change-Id: I17bfc3e421cda06c4cba40efb6de046bed66bd14 Reviewed-on: https://chromium-review.googlesource.com/1007843 Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Rick Byers <rbyers@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#550254} [modify] https://crrev.com/17b6ae06b685758f117ece8f123b513f39d2d942/third_party/blink/common/feature_policy/feature_policy.cc [modify] https://crrev.com/17b6ae06b685758f117ece8f123b513f39d2d942/third_party/blink/public/mojom/feature_policy/feature_policy.mojom [modify] https://crrev.com/17b6ae06b685758f117ece8f123b513f39d2d942/third_party/blink/renderer/platform/feature_policy/feature_policy.cc
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/17b6ae06b685758f117ece8f123b513f39d2d942 commit 17b6ae06b685758f117ece8f123b513f39d2d942 Author: Ehsan Karamad <ekaramad@chromium.org> Date: Thu Apr 12 17:32:51 2018 Introduce Feature Policy: vertical-scroll (bare feature) This CL introduces the bare feature. 'vertical-scroll' intends to block specific sandboxed frames (which do not have the feature enabled) from interfering with user's vertical scrolling in the page. The details are explained in the document: https://docs.google.com/document/d/1qiWelnMlsOHuT_CQ0Zm_qEAf54HS5DhoIvEDHBlfqps/edit?usp=sharing The actual logic for blocking such frames will land in follow-up CLs. Bug: 611982 Change-Id: I17bfc3e421cda06c4cba40efb6de046bed66bd14 Reviewed-on: https://chromium-review.googlesource.com/1007843 Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Rick Byers <rbyers@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#550254} [modify] https://crrev.com/17b6ae06b685758f117ece8f123b513f39d2d942/third_party/blink/common/feature_policy/feature_policy.cc [modify] https://crrev.com/17b6ae06b685758f117ece8f123b513f39d2d942/third_party/blink/public/mojom/feature_policy/feature_policy.mojom [modify] https://crrev.com/17b6ae06b685758f117ece8f123b513f39d2d942/third_party/blink/renderer/platform/feature_policy/feature_policy.cc
,
Apr 25 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/52399752c4ae1a648fc8b5dd40e3bea41e39e19b commit 52399752c4ae1a648fc8b5dd40e3bea41e39e19b Author: Ehsan Karamad <ekaramad@chromium.org> Date: Wed Apr 25 15:20:27 2018 'vertical-scroll' for programmatic scrolling If 'vertical-scroll' is disabled for an <iframe>, then it should not be able to affect the vertical scroll position. One way to block is to use scripted scrolling by calling "element.scrollIntoView()". To block such frames (whose feature's disabled), programmatic recursive scroll calls are not forwarded to parent frames. This means if a given <iframe> is blocked, then all the calls to scrollIntoView() are limited to the scope of frame (i.e., elements becoming visible in the frame). This applies to all the nested <iframe>'s of a disabled frame as well since they would have the feature disabled as part of propagating the container policy. Link to explainer/design document for "vertical-scroll": https://docs.google.com/document/d/1qiWelnMlsOHuT_CQ0Zm_qEAf54HS5DhoIvEDHBlfqps/edit?usp=sharing Bug: 611982 Change-Id: I0e06b399ad890e263128b997cfbb04eb3bdd1494 Reviewed-on: https://chromium-review.googlesource.com/1014191 Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: Ehsan Karamad <ekaramad@chromium.org> Reviewed-by: David Bokan <bokan@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#553561} [add] https://crrev.com/52399752c4ae1a648fc8b5dd40e3bea41e39e19b/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/resources/vertical-scroll-scrollintoview.html [add] https://crrev.com/52399752c4ae1a648fc8b5dd40e3bea41e39e19b/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/resources/vertical-scroll.js [add] https://crrev.com/52399752c4ae1a648fc8b5dd40e3bea41e39e19b/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-scrollintoview.tentative.sub.html [modify] https://crrev.com/52399752c4ae1a648fc8b5dd40e3bea41e39e19b/third_party/blink/renderer/core/layout/layout_box.cc [modify] https://crrev.com/52399752c4ae1a648fc8b5dd40e3bea41e39e19b/third_party/blink/renderer/core/layout/layout_box.h
,
Apr 27 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/195b614b7bf891be26a9f297e6688a4381a880da commit 195b614b7bf891be26a9f297e6688a4381a880da Author: Ehsan Karamad <ekaramad@chromium.org> Date: Fri Apr 27 18:51:15 2018 Rename a WPT The test does not require nor use "server-side substitution" and the flag ".sub" was left by mistake. Bug: 611982 Change-Id: I5674911c22d1fb55e7aa41125d343966f4b8a84f Reviewed-on: https://chromium-review.googlesource.com/1033352 Reviewed-by: Ian Clelland <iclelland@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#554432} [rename] https://crrev.com/195b614b7bf891be26a9f297e6688a4381a880da/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-scrollintoview.tentative.html
,
May 2 2018
Adding a quick update to this bug.
We are now tracking the implementation of this through feature policy ('vertical-scroll'). 'touch-action' and 'scrollIntoView()' are now considered as methods of interfering with scroll and now covered under the 'vertical-scroll' umbrella (i.e., frames which are disallowed 'vertical-scroll' cannot extend the scope of scrollIntoView() to outside and all their touch-actions are forced to include 'pan-y'.
There possibly are some other methods for blocking scroll that we might need to address. On desktop at least, one way I found is to embed flash. I am less worried about PDF since it is embedded inside a component extension which can be zoomed out and scrolled.
,
May 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d7e9702df54d7b686878eefaf1ec60647d425987 commit d7e9702df54d7b686878eefaf1ec60647d425987 Author: Ehsan Karamad <ekaramad@chromium.org> Date: Mon May 07 17:31:53 2018 Override 'touch-action' for 'vertical-scroll' With "vertical-scroll 'none'" as a feature set for an <iframe>, we want to make sure the <iframe> cannot prevent the user from vertically scrolling the page. One way of blocking user is to exclude "pan-y" from "touch-action". This CL makes sure that when an element is inside such frames, the "touch-action" always includes "pan-y". Link to explainer/design document: https://docs.google.com/document/d/1qiWelnMlsOHuT_CQ0Zm_qEAf54HS5DhoIvEDHBlfqps/edit?usp=sharing Bug: 611982 Change-Id: Ie60c665de3c82ec2438bcea10f56b54d51084eda Reviewed-on: https://chromium-review.googlesource.com/1014389 Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Reviewed-by: Ian Clelland <iclelland@chromium.org> Reviewed-by: David Bokan <bokan@chromium.org> Reviewed-by: Jonathon Kereliuk <kereliuk@chromium.org> Cr-Commit-Position: refs/heads/master@{#556484} [modify] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/WebKit/LayoutTests/TestExpectations [add] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/resources/vertical-scroll-touch-action.html [add] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-touch-action-manual.tentative.html [add] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll-touch-action-manual.tentative-automation.js [add] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll.js [modify] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/WebKit/LayoutTests/resources/testharnessreport.js [modify] https://crrev.com/d7e9702df54d7b686878eefaf1ec60647d425987/third_party/blink/renderer/core/css/resolver/style_adjuster.cc
,
May 10 2018
FYI, as I was thinking about the use cases for this I realized there are sites where horizontal scrolling is the main scrolling axis, for example the news carousel on search results is conceptually a horizontal scroller with vertically scrolling subframes. We may want to have a similar feature policy which always allows horizontal panning. I filed issue 841668 to track this.
,
May 10 2018
It also occurred to me that another annoying pattern which I've seen in a few cases are child frames which are scrollable in the vertical direction. If you accidentally start your scroll on these frames it could effectively "block" your vertical scroll of the main frame. Perhaps another part of this policy should be to also not consider the child frame for scrolling.
,
May 10 2018
comment #23: IIUC, the issue is with child frames which have elements that can scroll indefinitely or at least have very large scrollable contents, right? To disable scrolling for those altogether seems like a solid and consistent but a bit too restrictive resolution. I wonder if it makes sense to through this policy distribute scroll more evenly in the scroll chain (maybe scroll customization). In other words, make sure any gesture scroll is partly applied on the parent in the chain (first parent with the feature on).
,
May 10 2018
Since we expect this to be applied on frames like ads, I think it wouldn't be overly restrictive at all to say that the frame can't have any user-initiated vertical scrolling of it's own. I.e. maybe we just never let the GestureScroll sequence go down into the frame at all? Regarding flackr's suggestion of the equivalent horizontal-scroll scenario: this is effectively what AMP already does. Horizontal scrollers are banned in AMP pages for exactly this reason. It seems reasonable to me to disallow horizontal GestureScroll sequences to go down into such frames.
,
May 30 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e commit 7f60dea1095de7e81fedbd660e8f3e119dc6ce2e Author: Ehsan Karamad <ekaramad@chromium.org> Date: Wed May 30 16:07:16 2018 Ignore preventDefault() for 'vertical-scroll' This CL adds the logic to ensure calling event.preventDefault() will not block vertical scrolling for frames which do not have the feature policy enabled. Essentially, the response from dispatching the dom event is overwritten by "not canceled" and the event is marked as not prevented. In line with this, and in order to make sure only vertical scroll is enforced, the allowed touch action is set to 'pan-y'; then any scrolling along the x-axis can still be blocked by prventDefault()-ing the event. Bug: 611982 Change-Id: Iba371be063bf064601ecce6e930424c4fb11ac26 Reviewed-on: https://chromium-review.googlesource.com/1053175 Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/master@{#562856} [modify] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/WebKit/LayoutTests/TestExpectations [add] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/resources/vertical-scroll-touch-block.html [add] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-touch-block-manual.tentative.html [add] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll-touch-block-manual.tentative-automation.js [modify] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll.js [modify] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/blink/renderer/core/input/touch_event_manager.cc [modify] https://crrev.com/7f60dea1095de7e81fedbd660e8f3e119dc6ce2e/third_party/blink/renderer/core/input/touch_event_manager.h
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/77e042ca83a68a0a1a11691683f380569840edc5 commit 77e042ca83a68a0a1a11691683f380569840edc5 Author: Ehsan Karamad <ekaramad@chromium.org> Date: Fri Jun 15 20:09:34 2018 Ignore preventDefault on wheel (vertical-scroll) This CL implements the logic required for enforcing 'vertical-scroll' (through feature policy) on frames where a preventing mouse wheel handler may block vertical scrolling. The CL essentially overwrites the value of dispatch type from mouse wheel handlers iff the suggested direction of scrolling is vertical. Bug: 611982 Change-Id: I15230f11f616d093b21984fe0b526d94dc62dada Reviewed-on: https://chromium-review.googlesource.com/1073729 Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/master@{#567773} [add] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/resources/vertical-scroll-wheel-block.html [modify] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-touch-action-manual.tentative.html [modify] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-touch-block-manual.tentative.html [add] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/WebKit/LayoutTests/external/wpt/feature-policy/experimental-features/vertical-scroll-wheel-block-manual.tentative.html [add] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll-wheel-block-manual.tentative-automation.js [modify] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll.js [modify] https://crrev.com/77e042ca83a68a0a1a11691683f380569840edc5/third_party/blink/renderer/core/input/mouse_wheel_event_manager.cc
,
Aug 30
,
Aug 31
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/45445c29b05c4b503e6188f8fd67177889d13f8a commit 45445c29b05c4b503e6188f8fd67177889d13f8a Author: Ehsan Karamad <ekaramad@chromium.org> Date: Fri Aug 31 14:31:30 2018 Remove 'eventSender' from vertical-scroll tests The vertical scroll tests use wheel and touch gestures. The wheel gesture uses window.eventSender which is a deprecated and non-realistic API. This CL will remove the dependency by using chrome.gpuBenchmarking.smoothScrollBy API instead. In addition to this change, the current API for touch scrolling is also changed into using the smoothScrollBy method. Bug: 611982 Change-Id: I6f3d65756dcba74be0e5dc7a7fa053d88ecbdef9 Reviewed-on: https://chromium-review.googlesource.com/1197042 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#588017} [modify] https://crrev.com/45445c29b05c4b503e6188f8fd67177889d13f8a/third_party/WebKit/LayoutTests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll.js
,
Nov 17
I am closing this bug since 'vertical-scroll' is now implemented behind a flag. This however does not mean sandbox <iframe>'s are getting the policy by default.
,
Nov 19
Is there another bug to track the remaining work to shipping this (on by default)?
,
Nov 19
The remaining work for VS is mostly optimization e.g., handling wheel on the compositor...so the feature itself is complete. However, we should make sure we want the current behavior to be applied to *all* sandbox frames; in short, the feature currently: 1- Blocks a frame from canceling touch and wheel or using a touch-action setting that does not include pan-y. 2- Keeps the scope of "scrollIntoView" to frame (no change in scroll offset of the parent). 3- Does not target the <iframe> for scrolling and does not show scrollbars. So a document which does not have "vertical-scroll" feature enabled *cannot* be scrolled. I think due to (3) enabling this feature on *all* sandboxed frames might be problematic. Removing the condition in (3) will also regress issue 853485 . Alternatively we could keep (3) but show scrollbars and somehow make sure the <iframe> can still be scrolled if the user uses the scrollbars.
,
Dec 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd1c8c18a8b74e8c02fea5d6d1e62b9bff65ae3d commit bd1c8c18a8b74e8c02fea5d6d1e62b9bff65ae3d Author: Ehsan Karamad <ekaramad@chromium.org> Date: Tue Dec 18 20:21:59 2018 vertical-scroll: Policy will not affect main document The purpose of 'vertical-scroll' is to block sub-frames from interfering with main-frame's scrolling. To enforce the policy on the main frame is wrong in that it will block all scrolling on the page. This CL will special-case the main frame scenairo and will not enforce the policy. Same-origin subframes are still affected. TBR=iclelland@chromium.org Bug: 611982 Change-Id: I2fbe882cc65af6f7ed542ebc0151df9f281e9ab2 Reviewed-on: https://chromium-review.googlesource.com/c/1378684 Reviewed-by: David Bokan <bokan@chromium.org> Commit-Queue: Ehsan Karamad <ekaramad@chromium.org> Cr-Commit-Position: refs/heads/master@{#617603} [modify] https://crrev.com/bd1c8c18a8b74e8c02fea5d6d1e62b9bff65ae3d/third_party/blink/renderer/core/dom/document.cc [add] https://crrev.com/bd1c8c18a8b74e8c02fea5d6d1e62b9bff65ae3d/third_party/blink/web_tests/external/wpt/feature-policy/experimental-features/vertical-scroll-main-frame-manual.tentative.html [add] https://crrev.com/bd1c8c18a8b74e8c02fea5d6d1e62b9bff65ae3d/third_party/blink/web_tests/external/wpt/feature-policy/experimental-features/vertical-scroll-main-frame-manual.tentative.html.headers [add] https://crrev.com/bd1c8c18a8b74e8c02fea5d6d1e62b9bff65ae3d/third_party/blink/web_tests/external/wpt_automation/feature-policy/experimental-features/vertical-scroll-main-frame-manual.tentative-automation.js |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by rbyers@chromium.org
, May 14 2016