New issue
Advanced search Search tips

Issue 820533 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocking:
issue 791225



Sign in to add a comment

Rubber-banding of main frame causes local iframe in OOPIF to be unscrollable.

Project Member Reported by mcnee@chromium.org, Mar 9 2018

Issue description

Chrome Version: 66.0.3359.0
OS: macOS 10.12.6

Initially reported by mehmet@: crbug.com/807683#c49

What steps will reproduce the problem?
(1) Run chrome with --site-per-process
(2) Visit chromium.org/developers/calendar
(3) Scroll down the page until the rubber-banding effect activates at the bottom of the page
(4) Scroll back up to the table of version numbers
(5) Attempt to scroll the inner iframe

What is the expected result?
The inner iframe should scroll.

What happens instead?
The inner iframe does not scroll. The scroll is bubbled instead.

Further information from 807683:
Device: iMac 21,5 (2012) Non-Retina and MagicMouse1
mehmet@ reported that it does not reproduce with --disable-threaded-scrolling, indicating an issue with the compositor thread.

Initial hypothesis from wjmaclean@:
"I suspect the rubber-banding issue occurs because, when the rubber-banding is invoked in the main-frame's renderer (and not in the OOPIF's renderer), there is at present no way for the OOPIF's ScrollingCoordinator to know to call UpdateAfterCompositingChangeIfNeeded ... although it may get called for other reasons, causing the NFSRs to get changed during rubber-banding but not again afterwards."
 

Comment 1 by mcnee@chromium.org, Mar 9 2018

Blocking: 791225
horizontal_scrolling.mov
12.1 MB View Download

Comment 2 by mcnee@chromium.org, Mar 9 2018

Cc: meh...@chromium.org

Comment 3 by mcnee@chromium.org, Mar 26 2018

I can't seem to reproduce this on canary (67.0.3379.0).

mehmet@: Is this issue still happening for you?

Comment 4 by meh...@chromium.org, Mar 27 2018

mcnee@: Seems to work now in latest Canary with your steps from comment 0. Thanks!

Comment 5 by mcnee@chromium.org, Mar 27 2018

Status: Fixed (was: Assigned)
Marking fixed as per c#4.
mcnee@: Do we understand what fixed this issue and (more importantly) whether this is broken in M66?

Comment 7 by mcnee@chromium.org, Apr 12 2018

Re c#6: Don't know. I wasn't able to reproduce this on the version from the original report.

Sign in to add a comment