I can repro on ChromeOS on version 63.0.3239.140 as well.  Seems to be a high DPI issue.

It does sound similar to issue 803227.  oshima@, can you check if these are the same underlying bug?  Thanks!

Am I correct that the issue is the scrollbar not being updated? I could scroll down using wheel gesture without scrolling up. Tested on PixelBook + 63.0.3239.140 and 66.0.3226

No, the bug is that the whole page scrolls instead of just the iframe (after scrolling the iframe to the bottom and then using the button to add content to it).  I found I needed to carefully follow the repro steps on https://peteblois.github.io/tmp/iframe_scrolling_page/ to observe it.

Note that the bug is more pronounced in Chrome 63.0.3239.140 on ChromeOS if you do an aggressive/fast scroll down in step 4.  If you do a small/controlled scroll down, the page starts to scroll down and then the iframe scrolls instead.

I've just repro'd the bug on a Chromebook Pixel 2 with 65.0.3325.9 as well.  There, the speed of the scroll doesn't matter-- only the page scrolls, not the iframe.  (Maybe that's due to scroll latching being enabled.)

I've also confirmed that the bug does not repro on non-high-DPI machines, including Mac and Windows.  (Presumably it would affect high DPI Windows/Linux as well, though I don't have a way to test that.)  Updating labels to show this affects both M63 and M65.

Friendly ping.  Are you able to repro the issue given the additional information in comments 5-7?

We could also check if lfg@'s https://chromium-review.googlesource.com/c/chromium/src/+/882021 resolves this, similar to the effect it had on issue 803227.

re comment 6: The bug is reported on M63 when wheel scroll latching is disabled, I don't think latching is related.

On mac when you change the setting to always show the scrollbars, the issue isn't reproducible.

> high DPI Windows/Linux as well, though I don't have a way to test that.

FYI: DPIness related issues are almost always related to whether we composite non-frame scrollers. You can go either way using flags:

On Low DPI machine simulate high DPI: --enable-prefer-compositing-to-lcd-text
On High DPI machine simulate low DPI: --disable-prefer-compositing-to-lcd-text

You can also use --force-device-scale-factor=1 or 2 depending on what you want.

This one also seems to be a platform dependent.
On ChromeOS, this happens even on normal DPI device, while on linux it doesn't happen regardless of scale factor.

creis@ can you test it on linux build?

Here is the video on chromeos + 1x dsf and linux + 2x dsf

linux + 2x dsf
https://drive.google.com/file/d/1AyPeallr3JbORv-lC90FDk1sPVaPLxxH/view?usp=sharing

chomeos + 1x dsf
https://drive.google.com/file/d/1hGaL2bMFvcy593dWD53tOA_EVPm0dk_x/view?usp=sharing

Looks like this is actually an issue with OverlayScrollbar. It doesn't happen when I disabled it on ChromeOS + 2x dsf.

https://drive.google.com/file/d/1Vv8lI19qwAeuL2wnI4_S3C8pM9FeBzsz/view?usp=sharing

bokan@, skobes@ can you find the right owner for this?

I'll take a look tomorrow.

Comment 15: Confirmed.  Disabling chrome://flags#overlay-scrollbars does make the problem go away on my Chromebook Pixel 1 (running 65.0.3325.35).  (And re: comment 13: I do not see the problem on my low DPI Linux box, even when using --force-device-scale-factor=2.)

Given the similarity to issue 803227, maybe it's worth checking to see if lfg's https://chromium-review.googlesource.com/c/chromium/src/+/882021 CL helps here as well?  (If so, we should try to understand why.)

I'm able to repro on Linux with: --site-per-process  --enable-prefer-compositing-to-lcd-text --enable-features=OverlayScrollbar

Building now with lfg@'s patch to see if that helps.

The patch does not help unfortunately. I'll dig in a bit deeper.

Found the bug. In ScrollingCoordinator::UpdateAfterCompositingChangeIfNeeded we exit early if we're in an iframe but the compositor's frame scrolling layer gets sized below that early-out:

  scroll_layer->SetBounds(frame_view->ContentsSize());

The reason scrolling up makes it work is because changing the scroll offset ends up calling ScrollingCoordinator::ScrollableAreaScrollLayerDidChange and that also sets the frame scroll layer's size. Non-overlay scrollbars presumably also perform some sort of update that does this (as changing overflow can cause scrollbars to (dis)appear which can cause the scrolling layer to change size).

Over to James since the TODO there is his. I believe the fix might be as simple as moving that SetBounds call up to before the early-out (this fixes the repro for me).

A fix for this has been landed at https://chromium-review.googlesource.com/905273

+ govind@, nasko@

I've uploaded a simplified (and potentially mergeable) fix for this issue at

https://chromium-review.googlesource.com/c/chromium/src/+/913868

I can't test it on ToT as it conflicts with the CL from https://chromium-review.googlesource.com/905273, but testing it locally it looks ok.

Is there anyway to run it through the bots for the beta branch?

Comment 25: There aren't any try bots for beta branch, but you could build that branch locally to apply your change and test it.

I can confirm the r535797 fix in 66.0.3350.0 with chrome://flags/#overlay-scrollbars enabled on Windows.  Thanks!

However, I wonder if it may be too late to merge that smaller fix to M65, since M65 will soon reach stable.  My main concern is that the smaller fix wouldn't have any time to bake, since it doesn't match what landed in r535797.

The implication is that current Site Isolation users will continue to have this scrolling bug until M66.  That might be ok, since the workaround is just to scroll up slightly and then scrolling works again.

govind@: Do you agree?

Lets wait until M66 per comment #26 and offline chat with creis@.