It doesn't seem like a browser action popup. Rather it's an extension resource loaded in an iframe (the sidebar).
I tried scrolling the frame with two finger scrolling on mac and it seemed it's always sending those events to the page.
Are there issues with scroll events in isolate-extensions?
Assigning to Charlie for triage.

Note: In house was not able to generate any good build using per-revision bisect, tried changing the revisions. Hence using regular bisect to narrow down.

Thanks.!

Correction in Manual Bisect range:
Good build:58.0.3024.0
Bad build:58.0.3026.0

Narrow bisect :
https://chromium.googlesource.com/chromium/src/+log/32e074e42207bf161510aba4c4b5539d0818d2f1..ecfcc163f15b17c9a04b1f62db1ff8cf11d9eccc?pretty=fuller&n=10000

Suspecting: r450821 ?

@nasko- Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner.

Adding Release block label, please undo if not the case.

While the CL pointed to might be the point at which change of behavior happened, it is not the root cause. It just enabled a feature we started shipping to all users.

Adding kenrb@ and wjmaclean@ as this is scrolling related.

Actually adding kenrb@ and wjmaclean@ :).

I've been looking at some mouse-wheel stuff just recently, so I can triage this ...

Ok, my initial thoughts are that this is a scroll-bubbling issue between an OOPIF and it's parent frame, possibly related to mouse-in/out handling?

In any case, it seems wrong (to me at least) that we would let scrolls bubble out of an extension frame and into the main frame, but then I guess once the extension has added its content to the host document, it's part of that document? Probably not the behaviour you'd expect though.

Sadly, trying to call Inspector on the extension iframe crashes the extension frame, so it's hard to tell why the drop-down list doesn't get the scrolls before the frame that it's in.

I'll try to spend some time tomorrow looking at the bubbling-into-the-mainframe issue (although this may be the expected behaviour, even if somewhat unexpected).

Interesting that this doesn't repro on 57.0.2987.88, even with Isolate Extensions enabled.  (I was concerned it might be present on M57 and M56 if that mode is turned on, but it doesn't seem to be the case.)  James, do you know of anything recent that might have affected this?

Thanks for the heads-up about the good revision ... in that case the simplest thing would be a bisect (coming right up!)

Ok, this one's on me, as the culprit is

https://codereview.chromium.org/2479663002

This is the CL to move InputHandler from RenderViewImpl to RenderWidget. I'll dig further to see why the scroll events aren't going through. It seems the custom scroll-list code has a mousewheel handler, which is potentially related to what the CL is about.

Ok, I'm narrowing in on this. Seems like we're assigning the scrolls for the custom list to the impl thread when we shouldn't: somewhere in the vicinity of

https://cs.chromium.org/chromium/src/ui/events/blink/input_handler_proxy.cc?rcl=419a628d898182f01fe1974bca078351ef4660cb&l=816

If I manually override and force it back onto main it's ok, so it seems likely we're just doing the test for the existence of the wheel handler wrong.

Continuing to dig ...

Ok, I think I have a handle on this, though a CL that verifies I'm correct will need to be put together.

This is the mouse-wheel equivalent of the problem we had with ScrollingCoordinator not setting "touch handler rects" for OOPIF subframes. In this case, SC isn't setting the nonFastScrollableRegion() that goes along with the kBlocking MouseWheelHandler.

Just as in the touch-rect case, I think the short term solution is to set the entire OOPIF subframe as nonFastScrollable if there's a blocking wheel handler. Not optimal, but it will give correct behaviour with no more penalty than we had prior to enabling composited scrolling for OOPIFs.

The long-term solution is of course to fix ScrollingCoordinator (https://bugs.chromium.org/p/chromium/issues/detail?id=680606).

I'll put together a CL to implement a fix for testing.

+CrOS since this almost certainly will manifest there as well.

See RenderWidgetCompositor::updateTouchRectsForSubframeIfNecessary() in https://codereview.chromium.org/2479663002/ for details about touch-handler-rects mentioned in comment above.

It would be nice if the nonFastScrollableRegion and touchHandlerRect code could be coalesced ... not sure off hand just how hard that would be ...

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

commit 47b1b819e0e239b1c753ae4e736f77ac9ccafcdd
Author: wjmaclean <wjmaclean@chromium.org>
Date: Fri Mar 10 19:24:24 2017

Mark sub-frame root layer non-fast scrollable when wheel handlers present.

Just like with touch event handlers, at present a sub-frame's
compositor does not receive regions rects for non-fast scrollable
regions that accompany MouseWheel handlers. Until ScrollingCoordinator
is made per-frame, we should mark the entire root layer rect as
non-fast scrollable in the presence of blocking wheel handlers.

The primary changes are all in render_widget_compositor.cc; other
files are touched only to give the function a more inclusive name.

BUG= 698195 

Review-Url: https://codereview.chromium.org/2740133002
Cr-Commit-Position: refs/heads/master@{#456131}

[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/content/renderer/gpu/render_widget_compositor.h
[add] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/content/test/data/page_with_scrollable_div.html
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/third_party/WebKit/Source/core/loader/EmptyClients.h
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/third_party/WebKit/Source/core/page/ChromeClient.h
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/third_party/WebKit/Source/web/ChromeClientImpl.cpp
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/third_party/WebKit/Source/web/ChromeClientImpl.h
[modify] https://crrev.com/47b1b819e0e239b1c753ae4e736f77ac9ccafcdd/third_party/WebKit/public/platform/WebLayerTreeView.h

This should now be fixed in tip-of-tree. Please re-open if the issue recurs.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-58; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-58 label, otherwise remove Merge-TBD label. Thanks.

[Ugh ... collides with blockerbot@ when trying to add merge-request label ... ]

We don't need to merge the function name changes, just the changes in render_widget_compositor.cc, if that makes the merge any easier.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

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

Please merge your change to M58 branch 3029 before 5:00 PM PT, Monday (03/13/17) so we can take it in for next week dev release. Thank you!

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

commit e4c4f772242dae97a0503437a4001b5b22a357a7
Author: W. James MacLean <wjmaclean@chromium.org>
Date: Mon Mar 13 13:56:36 2017

Mark sub-frame root layer non-fast scrollable when wheel handlers present.

Just like with touch event handlers, at present a sub-frame's
compositor does not receive regions rects for non-fast scrollable
regions that accompany MouseWheel handlers. Until ScrollingCoordinator
is made per-frame, we should mark the entire root layer rect as
non-fast scrollable in the presence of blocking wheel handlers.

The primary changes are all in render_widget_compositor.cc; other
files are touched only to give the function a more inclusive name.

BUG= 698195 

Review-Url: https://codereview.chromium.org/2740133002
Cr-Commit-Position: refs/heads/master@{#456131}
(cherry picked from commit 47b1b819e0e239b1c753ae4e736f77ac9ccafcdd)

Review-Url: https://codereview.chromium.org/2743223003 .
Cr-Commit-Position: refs/branch-heads/3029@{#146}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/content/browser/site_per_process_browsertest.cc
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/content/renderer/gpu/render_widget_compositor.h
[add] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/content/test/data/page_with_scrollable_div.html
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/third_party/WebKit/Source/core/frame/FrameView.cpp
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/third_party/WebKit/Source/core/loader/EmptyClients.h
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/third_party/WebKit/Source/core/page/ChromeClient.h
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/third_party/WebKit/Source/web/ChromeClientImpl.cpp
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/third_party/WebKit/Source/web/ChromeClientImpl.h
[modify] https://crrev.com/e4c4f772242dae97a0503437a4001b5b22a357a7/third_party/WebKit/public/platform/WebLayerTreeView.h

James, are you able to verify the fix for this on Canary?  I just filed  issue 701178  which seems closely related but occurs even with your fix.

Tested the issue on windows 7, Mac 10.12.3, Linux Ubuntu 14.04 using chrome version#58.0.3029.19 with the steps mentioned in comment #0.
Observed that the Scrollbar within the dropdown is working as intened using mouse wheel. Hence adding TE-Verified labels.
Please find the attached screen cast for the same.
Thanks!!

Deleted: 698195.mp4 570 KB

	698195.mp4 570 KB View Download