This issue can reproduce with latest code on my machine when I set a user-data-dir but it works correctly when using default user-data-dir (~/.config/chromium/Default). I have tried delete my user-data-dir and delete default user-data-dir.

When it works incorrect:

FindLayerThatIsHitByPoint in LayerTreeHostImpl::MouseMoveAt returns a same layer for this page. 

Does it still work after you clear out the default user-data-dir? That'd be strange. Perhaps you have some about:flags that are causing a difference?

It is caused by site-per-process (OOPIF?). It works correctly when enable.

Ah, good catch. site-per-process is indeed OOPIF. An OOPIF local root will have its own compositor, so as far as its compositor is concerned, it's a "root frame". I'm guessing there's some logic that doesnt work when the layer tree has a (non-OOPIF) iframe with a scroller inside it. Perhaps we're hitting the iframe layer? Still, I feel like this is weird, AFAIK, iframes are treated just like any other scrolling layer in the compositor.

You should probably build a simplified example that has just an iframe with a scroller inside it. That should help you with identifying layers (the jsfiddle will have dozens/hundreds of layers). +wjmaclean@ in case he knows of anything special about non-OOPIF iframes in the compositor.

The Debug info for the unexpected layer:

Layer 58
{bounds: {height: 631,
          width: 17841},
 cat: "disabled-by-default-cc.debug",
 opacity: 1,
 pictures: [{idRef: "0x10e5065cb000"}],
 position: [-15285,
            -6],
 tilings: [{contentScale: 1,
            eventuallyRect: Rect(12193, 0, 5648, 631),
            numTiles: 69,
            rasterTransform: [1,
                              0,
                              0],
            skewportRect: Rect(15285, 6, 2550, 615),
            soonRect: Rect(14973, -306, 3174, 1239),
            tilingSize: {height: 631,
                         width: 17841},
            visibleRect: Rect(15285, 6, 2550, 615)}],
 baseType: "cc::LayerImpl",
 canHaveTilingsState: {canHaveTilings: true,
                       drawsContent: true,
                       maxContentsScale: 1,
                       minContentsScale: 0.0625,
                       rasterSourceHasRecordings: true,
                       rasterSourceSolidColor: false},
 canUseLcdText: false,
 compositingReasons: ["Secondary layer, home for a group of squashable content"],
 contentsOpaque: false,
 drawsContent: 1,
 gpuMemoryUsage: 2883584,
 hasAnimationBounds: false,
 hasWillChangeTransformHint: false,
 idealScales: {contentsScale: 1,
               deviceScale: 1,
               pageScale: 1,
               sourceScale: 1},
 layerName: "Squashing Layer (first squashed layer: LayoutBlockFlow (positioned) A class='windowLabel')",
 mainThreadScrollingReasons: [],
 ownerNode: 32,
 rasterScales: {contentsScale: 1,
                deviceScale: 1,
                lowResContentsScale: 0.25,
                pageScale: 1,
                sourceScale: 1},
 screenSpaceTransform: [1,
                        0,
                        0,
                        -15285,
                        0,
                        1,
                        0,
                        -6,
                        0,
                        0,
                        1,
                        0,
                        0,
                        0,
                        0,
                        1],
 scrollOffset: [0,
                0],
 squashingDisallowedReasons: [],
 tilePriorityRect: Rect(15285, 6, 2550, 615),
 touchEventHandlerRegion: [16652,
                           61,
                           8,
                           137,
                           15475,
                           198,
                           2362,
                           8,
                           16652,
                           206,
                           8,
                           425],
 visibleRect: Rect(15285, 6, 2550, 615)}

Deleted: Screenshot from 2017-04-28 14:26:41.png 8.6 KB

	Screenshot from 2017-04-28 14:26:41.png 8.6 KB View Download

Could you create a minimal repro case so that the rest of jsfiddle isn't getting in the way here?

It looks like this is a squashing layer. I wonder if its getting in the way of the mouse inadvertently here. +vollick@, we're missing mouse moves on a compositor scrolling layer and it seems to be hitting a squashing layer instead. Do you have any tips on how to debug this do some more digging? Or, if you're too out of the loop here, who else might be able to help Chao (preferably in WAT)?

Actually, this makes a lot of sense. vollick, correct me if I'm wrong. If you have two layers that are far apart and get squashed into one, the resulting squashing layer will be the bounding box of the two. This means it'll overlay anything below it but inbetweeen the two original layers:

______                    _______
|    |   ______________   |     |
|  A |   |Our Scroller |  |  B  |
|____|   |             |  |_____|
         |_____________|

If A and B get squashed, the resulting layer will look like this:

_________________________________                   
|        ______________         |
|  A     |Our Scroller |     B  |
|________|_____________|________|
         |_____________|

So the mouse events over our scroller will go to the squashed A+B layer. If so, this may throw a serious wrench into our overlay scrollbars plan.

I can not reproduce it on a simple page. http://ht.chaopeng.me/script-modify-scrolling-2.html

Yah, I think you'd need to set it up so that you have two elements on opposite corners of your scroller that get squashed into one layer. I don't quite know the rules by which we decide when to squash something, vollick@ or someone else on the graphics team might be able to help here.

I wonder how come we can still wheel over the scroller. Chao, could you look into that? Are mouse wheels over a squashed layer routed to the main thread? If we're lucky, there's some extra information on the squashed layer that wheels are using to target correctly and we just need to use that for mouse moves as well.

Yes, this can indeed happen. We have a heuristic to prevent these squashing layers from getting too malformed (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/SquashingDisallowedReasons.cpp?rcl=280730d8d929cb3a28d5f78ba81cde790442dc30&l=17), but you can indeed get into this situation. +rjkroege, who has been thinking a lot about hit testing lately.

This is a problem with how the existing OOPIF surface hittest implementation works: it incorrectly handles squashed layers. There is a plan to resolve this and work is started for a new event targeting implementation that will resolve the issue. 

After talk with rjkroege@, this issue is not the same issue rjkroege@ working on since this issue can reproduce with site-per-process off.

I dug into why the squashing contents layer was so large and filed issue 719607 for the cause. It is not actually due to squashing far apart layers but instead because the overflow rect for the #home element extends to -900em due to their margin-left.

+chris, walter, on this JSFiddle chaopeng is seeing that the squashing layer is above all of the other layers (covering pretty much the entire page). I'm guessing because some of the squashed layers have a high z-index (like #header) this squashing layer ends up above the other layers. Since afaik we don't have a way to pass hits through then we'll have to go to main for all hit testing which will slow down this site (and others like it).

I worry this could be a common pattern; having top and/or left elements "above" the content seems to be a common design. Maybe we need to take this into account when layer squashing.

Re #17: but the #home element should only extend to the left offscreen, right? And it shouldn't have any overflow below the top nav bar. So unless it gets squashed with something below, it shouldn't be affecting hit-testing of the overflow scrollers in content area.

Removing the text-indent property on #home doesn't solve this issue. Deleting the fieldset.column.left element does fix it.

Right, it must also be getting squashed with layers below, but this seems like expected behavior. I think we need to either track squashed layer regions (so that we can hit test through them), or modify squashing to try to avoid large transparent regions (similar to the intent of the code mentioned in #13).

Unfortunately, not much we can do about this in the short term. But this should be rare and not a severe bug so lowering priority.

Can not reproduce anymore.