Further to the above, the issue is not present on laptop monitor, but is present on external monitor (Apple Cinema Display, using mini display-port)

Canary version in track above I _think_ is 68.0.3425.0, but can't be 100% as it crashes when I try to open chrome://settings/help (is there another way to check?)

chrome://version will give you the version.

Thanks: 68.0.3426.0 (Official Build) canary (64-bit)

Interesting - the compositor can't find a scrollable layer, saying the first is technically scrollable but with no overflow - the second isn't scrollable.

counterpointster@: I'm guessing your external monitor is high-DPI/retina but your laptop isn't? If you add |will-change: transform| to your scroller I expect it'll reproduce in both the laptop and external monitors.

Can you provide us with the failing content? A reduced test case would be best.

>I'm guessing your external monitor is high-DPI/retina but your laptop isn't?

The other way around, laptop is retina but external monitor isn't. I'll see if I can get more details based on what you suggest, thanks.

Looks like |will-change: trsnsform;| in the offending element removes the issue in the external monitor, the element now scrolls as expected.

From what I understand though, relying on this as a fix will negatively affect layout performance.

> The other way around, laptop is retina but external monitor isn't.

Ah - it's starting to make a bit more sense to me. We're on a low-DPI monitor so we don't create a compositing layer for the scroller but when we're handling the scroll on the compositor we don't forward it to the main thread. Sounds like we're missing or mis-positioning a MainThreadScrollRegion.

+flackr@: are you aware of any known bugs related to MainThreadScrollRegions?

counterpointster@: This is likely to depend on the content you have loaded. We're unlikely to be able to make progress without a reproduction test case.

Re: will-change: transform, it won't affect layout performance AFAIK - the main downsides are you'll lose LCD text antialiasing and you'll likely use a bit more GPU memory. The flip-side is that scrolling will be smoother and more responsive in more cases.

Had a chat with bokan@, the issue seems related to compositing.

flackr@ could you please triage it to the proper owner?

That would be nice. Though fun to watch tails being chased, as I will continue to as long as their 3rd with out my permission. 

Thanks! Went with applying the |will-change: transform| just on hover, should be fine.

Not sure if I'll be able to create a test case for this, it's a pretty complex layout/app, but I'll have a stab at it.

Would it help to have a trace for the working version (on the laptop monitor)? 

If so, do you want Chrome 66 or Canary 68 or both?

 Issue 841970  has been merged into this issue.

Ping, flackr@ - could someone from compositing team have a look at this? It seems there's a repro in  issue 841970 .

I looked at  issue 841970  but I'm not clear on what the repro case is. There are many sites with non-composited vertically scrolling elements which work fine, e.g. http://jsbin.com/cogoheb/edit?html,css,output

I looked for a repro in 841970 but it wasn't clear to me what the repro was - I tried the gist but it didn't seem to have any issues.

I wish I left more detail but I recall being able to repro a rather simple case - forget which now. Trying now I can't repro on any of the provided samples or my own so perhaps it's been fixed in 67 (also reported in  issue 841970   #2 ).

Going to close this. If anyone's still seeing this issue please reply with a repro here or file a new bug. Thanks!

I think this issue has not been fixed yet. It seems that this case will only happen with multi display devices. I just made a repro for the case hope it can help you to address this.

repro: https://drive.google.com/open?id=1-1v2TT2xCgG5NqfZYZdqT9-To7K4Yyug

How to reproduce:
Just open repro.html and try to scroll in center area which is marked with gray and white, after that you can find the element will not scrolled as expected. 
In the other hand, I noticed if you open dev-tool and resize it, this issue will be fixed temporary but once you have scrolled other node it will break again.

Other information:

UA: "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36"

Chrome:  67.0.3396.87 (stable)
OS: Windows 10 Pro 17134


Looking forward to your reply.

silver0x27@, can you put up the repro in a different format? Either attach the .html directly or, if it needs additional files, zip or tar it. Thanks.

bokan@

fyi

Deleted: chrome_scroll_issue_repro.zip 1.2 MB

chrome_scroll_issue_repro.zip 1.2 MB Download

Thanks - unfortunately I can't repro this on Surface Book Pro - Win 10. The config I was using is an external monitor set to "Extend Display". The laptop has a high DPI monitor and the external one is low DPI. The page scrolled as usual when tried on each monitor in both 67.0.3396.87 and 69.0.3466.0.

Does the issue still reproduce in Canary channel? Is one of your monitors different density than the other (i.e. UI scaling applied only one of the monitors)? Does the issue repro on both monitors?

Finally, could you capture and attach a trace here: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

I will try Canary later, but I'm sure this issue can only reproduce in external monitor.

In my case:

MBP with retina + DELL S2415Hb (reproduced
ASUS VX207DE + DELL lU2515H (reproduced

Just tried a MBP with external monitor. Can not reproduce. Did you tried it on Guest Mode?

MacBook Pro (Retina, 15-inch, Mid 2015)
Google Chrome	67.0.3396.87 (Official Build) (64-bit)
Revision	878cd31214ac27a3996927cd5c9c138b10c9fc8d-refs/branch-heads/3396@{#771}
OS	Mac OS X
JavaScript	V8 6.7.288.46
Flash	30.0.0.113
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

OP from  Issue 841970  I was able to replicate this on a my MacBook Pro (Retina, 15-inch, Mid 2014) last week but have since updated to Version 67.0.3396.99 (Official Build) (64-bit) and can no replicate the above repro on the external monitors 
 Apple LED Cinema Displays 
27" (5260x1440)
24" (1920x1200)

I am able to replicate the issue with the attached file, when the viewport width is less then the image width (1440px). 

However this works on all monitors not just external

On canary Version 69.0.3479.0 (Official Build) canary (64-bit) this is not an issue

Deleted: scratch_49.html 5.6 KB

scratch_49.html 5.6 KB View Download