candrada@, can you arrange to review this feedback?  It's for the M61 stable rollout, so time sensitive.

ramine@ is trying to repro.

Device: Sony Xperia Z5/7.1.1
Language: Japanese
Chrome version: 61.0.3163.98

Can you share which web site(s) did you visit?
-Thanks.

Here are more information from user feedback:

(1) User reported (https://listnr.corp.google.com/report/73954294739) responded to us saying it happens to all websites 

(2) Please find website links in following two new reports. One of these two users say this issue happens after "Stamina Mode" is on. 
https://listnr.corp.google.com/report/74103499527
https://listnr.corp.google.com/report/74097088365

Device: Sony Xperia Z5/7.1.1

Steps to repro:
1. Start Chrome and visit url 'https://appmedia.jp/fategrandorder/999237'
2. Try to scroll to the bottom of the page, pause and then scroll up

Results: 
Page gets stuck and scrolling halts several times before recovery.

Expected results:
Scrolling should be smooth and not sluggish.

Not able to repro with;
Chrome stable '60.0.3112.116'
Able to repro with Chrome '61.0.3163.98'

Added files at following link:

http://go/chrome-androidlogs1/7/767908

scrollingZ5.txt
scrollingZ5.mp4

Bisect Info:

Good build: 61.0.3136.4
Bad build:  61.0.3137.0
Regression range: https://chromium.googlesource.com/chromium/src/+log/61.0.3136.4..61.0.3137.0?pretty=fuller&n=10000
 
Good commit: 480802
Bad commit:  480803
Culprit CL: https://chromium.googlesource.com/chromium/src/+/7bfdda3f4d9e53f1f3f5848f7228834b62bbf6b1

Adding reviewers since hayleyferr@ is no longer here.

pdr/vmpstr, can you please take a look?  This is a regression in M61.

I was also able to repro it on Sony Xperia Z3 (D5803)/6.0.1 with same site as #7. Observed that page scroll doesn't work when the bottom 'ad' appears. If we fling at the right time between when the ad disappears and re-appears, scroll works.

I was able to reproduce this as well. There's nothing obviously wrong that stands out to me. Xida, can you investigate this?

We're actively holding up our M61 release since we're not sure how widespread we expect this bug to be, though it sounds pretty bad where we can reproduce it.  We need to understand:
 - How often we expect this bug to manifest in the wild (e.g. what circumstances lead to it)
 - If impactful enough to warrant considering holding for / fixing in M61, how risky the fix would be

Setting to Pri-0, please review ASAP.

+ pbommana@, could you please check whether you can repro  this on  hi-dpi desktop machines?

Vlad and I made a minimized reproduction case: http://jsbin.com/kugexus/quiet

This bug affects android and high-dpi devices.

The issue is that scrolling is incorrectly captured by a position:fixed scroller that should be behind another scroller. This is quite confusing because you cannot see the scrolling content and scrolling seems frozen. This situation is probably somewhat rare though.

I found that this affects all positioned content, not just positioned:fixed. Here is a testcase: http://output.jsbin.com/cofifiz/quiet

This reproduces for me on my highdpi mac and my pixel phone.

There was some confusion on how to reproduce this bug. Here are clearer reproduction steps:
1) Open http://jsbin.com/kugexus/quiet
2) Try to scroll the red area

What should happen: The red area should scroll.

What happens instead: the green area scrolls but the red area does not.

As suggested by Krishna to update this bug from Desktop perspective. 
We are not observing any significant feedback about this issue from Desktop users over 3 releases so far (61.0.3163.78, 61.0.3163.91, 61.0.3163.100)

This is impactful but we don't have enough evidence it's show stopping to warrant stopping the M61 rollout and respinning.  Let's ensure this is fixed for M62; updating labels to match.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50837c25c6a202ef3f2a9eeac56497a753431d11

commit 50837c25c6a202ef3f2a9eeac56497a753431d11
Author: Xida Chen <xidachen@chromium.org>
Date: Tue Sep 26 23:38:37 2017

Fix hit testing on hidpi

The underline issue of this bug is that there is a foreground_layer_
that should participate in hit testing, but we didn't set it in
CompositedLayerMapping.

This CL makes the foreground_layer_ hit testable.

Bug:  767908 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Icdede182921f576fe262f74f9a89cd6194563005
Reviewed-on: https://chromium-review.googlesource.com/685537
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#504521}
[modify] https://crrev.com/50837c25c6a202ef3f2a9eeac56497a753431d11/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/50837c25c6a202ef3f2a9eeac56497a753431d11/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMappingTest.cpp
[modify] https://crrev.com/50837c25c6a202ef3f2a9eeac56497a753431d11/third_party/WebKit/Source/platform/graphics/GraphicsLayer.h

Can haz merge to M62?

Maybe wait for tomorrow's canary channel to verify the fix?

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We are seeing more reports since M61 roll up to 100% (~10 reports per day). 
Below are reports come with URLs:
 
https://m.yahoo.co.jp/
https://listnr.corp.google.com/report/74402032750

http://sp.mbga.jp/_tpc_list?g=31287515
https://listnr.corp.google.com/report/74392215167

https://auone.jp/?rf=hm 
https://listnr.corp.google.com/report/74382603476

http://smt.docomo.ne.jp/?home_c 
https://listnr.corp.google.com/report/74379466551

I visited these sites in Chrome Stable (61) and was not able to reproduce their reports of not being able to scroll. That said, you may need to do something to get the bug to happen. I double-checked that my version of Chrome does have this bug. My intuition is that these users are seeing other bugs, or possibly have bad hardware.

Are ~10 reports per day of scrolling issues more than we saw with M60?

Yes, we saw ~3 reports in M60.  

Has the fix been verified in Canary?

I don't think the fix is in canary yet.

pdr@ is right, the fix didn't make it to today's canary.

I tried the URLs from #24 on some similar Sony device we have which poor network, turning ON accessibility, setting device language to JP, upgrade from M60->M61, etc. No luck reproing the issue so far. 
Device tried on: Sony Xperia Z5 (E6653), Sony Xperia A (SO-04E), SOny Xperia Z (SO-02E Docomo).

There are also logs available in most of the user reports. Not sure if they have any useful data around scrolling?

When the fix lands in canary, please verify it before requesting merge approval. 

Could someone verify whether this is fixed on today's canary

https://appmedia.jp/fategrandorder/999237 and http://jsbin.com/kugexus/quiet both work correctly now in chrome canary.

Verified that scroll works reliably in 63.0.3226.0 on https://appmedia.jp/fategrandorder/999237 and http://jsbin.com/kugexus/quiet .

Per comment #13 & #15, this bug affects high-dpi devices. 

OK, now it is verified that the scroll works. Please review the merge request.

Verified this on Windows 10 and Mac with latest Chrome canary i.e., 63.0.3226.0 with high DPI.

Approving merge to M62. Branch:3202

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6fd6850604d8bc770d04882972c0c38a65561d95

commit 6fd6850604d8bc770d04882972c0c38a65561d95
Author: Xida Chen <xidachen@chromium.org>
Date: Fri Sep 29 00:20:38 2017

Fix hit testing on hidpi

The underline issue of this bug is that there is a foreground_layer_
that should participate in hit testing, but we didn't set it in
CompositedLayerMapping.

This CL makes the foreground_layer_ hit testable.

Bug:  767908 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Icdede182921f576fe262f74f9a89cd6194563005
Reviewed-on: https://chromium-review.googlesource.com/685537
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#504521}(cherry picked from commit 50837c25c6a202ef3f2a9eeac56497a753431d11)
Reviewed-on: https://chromium-review.googlesource.com/691308
Reviewed-by: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#496}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/6fd6850604d8bc770d04882972c0c38a65561d95/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/6fd6850604d8bc770d04882972c0c38a65561d95/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMappingTest.cpp
[modify] https://crrev.com/6fd6850604d8bc770d04882972c0c38a65561d95/third_party/WebKit/Source/platform/graphics/GraphicsLayer.h

Verified this issue on Windows-10 HiDPI and MacBookPro 10.13 using chrome latest beta M62-62.0.3202.45 by following test case provided in comment #16, observed the red area scroll as expected but not the green area. The fix is working intended, hence adding TE-Verified label for M-62.

Thanks!

Android: Works as per expected behavior, scroll is working smooth. 
Issue verified on latest beta M62-62.0.3202.45 

xidachen@, can you please mark this as 'Fixed' if there is no CL is pending?

Thank you!