Issue metadata
Sign in to add a comment
|
Weird scrolling over OOPIF |
||||||||||||||||||||||
Issue descriptionVersion: 53.0.2774.0 OS: All What steps will reproduce the problem? (1) Run Chrome with --site-per-process flag. (2) Open http://csreis.github.io/tests/cross-site-iframe-simple.html. (3) Shrink the window vertically until the main page has a scrollbar as well. (4) Try to scroll with the cursor over the iframe. What is the expected output? I expect the frame to consume scrolling first, and then bubble when it can't scroll. What do you see instead? Both the frame and the main page scroll.
,
Jun 27 2016
+bokan, who I have been discussing this bug with offline.
,
Jul 4 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 8 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1 commit 3bdfea50bdfc6cc2b73c12969ca6207b5949fac1 Author: kenrb <kenrb@chromium.org> Date: Fri Jul 08 21:50:30 2016 Make RWHInputEventRouter manage cross-process scroll bubbling Mousewheel-based scroll bubbling from OOPIFs to parent frames was broken in a couple of ways, due to it improperly accounting for the mechanics of synthetic gesture scroll events from the InputRouter class. This refactors bubbling to do the following: - remove bubbling of unused scroll delta from WheelEvent acks, which was wrong, - pass acks from GestureScrollUpdate and GestureScrollEnd events to the CrossProcessFrameConnector and then have RWHInputEventRouter do most of the reasoning about where to target unused scroll, - track the current scroll bubbling target, which can change due to nested OOPIFs, and manage GestureScrollBegin and GestureScrollEnds to each renderer (the previous approach of wrapping each GestureScrollUpdate led to bubbled scrolls feeling really slow). BUG= 621624 CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2123843002 Cr-Commit-Position: refs/heads/master@{#404500} [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/frame_host/cross_process_frame_connector.cc [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/frame_host/cross_process_frame_connector.h [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/frame_host/render_widget_host_view_child_frame.h [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/renderer_host/render_widget_host_input_event_router.cc [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/renderer_host/render_widget_host_input_event_router.h [modify] https://crrev.com/3bdfea50bdfc6cc2b73c12969ca6207b5949fac1/content/browser/site_per_process_browsertest.cc
,
Jul 11 2016
Ken, can you check this is fixed on Canary?
,
Jul 12 2016
Just checked on Windows Canary, works fine. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by creis@chromium.org
, Jun 20 2016Labels: -Pri-2 Proj-IsolateExtensions-BlockingLaunch M-53 Pri-1
Status: Assigned (was: Untriaged)