Could be related to  https://crbug.com/831294  ???

Thanks for filing the issue!

As mentioned in Comment#1, even we feel this issue is similar to that of  Issue 831294 , Hence duplicating into it.

@sunxd: Please feel free to undupe if both aren't similar.

I don't have the permission to see the contents of http://crbug.com/823273, so I cannot really say if both are similar. I was just trying to offer extra help in solving this issue. The only way YOU would be able to tell if this is a dupe, is by going through both test cases???

In other words, please don't file this as a duplicate unless you know for sure it's a dupe, not acting on solely on my hunch of relation.

 Issue 831294  is a feature bug for shipping accelerated border radius element scrolling and it should have nothing to do with this.

However this one looks like a hit-testing issue, I think we treat the border as part of the layer when doing hit testing in compositor (but we have plans of implementing hit testing on the correct region in cc).

That said, I'm not sure if this is expected as the spec defined scrolling behavior on a border, cc bokan@ to verify this.

Yeah, this is an unfortunate known issue but likely won't see a resolution in the very near term

Just wanted to be clear as far as "this is expected as the spec defined scrolling behavior on a border" not relating to this issue. This issue scrolls a whole different scroller from the elements border where the scrolling happens.

But regardless, I see this is a dupe of another issue and its fix may be delayed for some time.

Ah...thanks for your patient explanations. I see the issue now (it requires that you be on a high-dpi screen - so both scrollers are composited). When you scroll over the bottom-right scroller's border, it causes scrolling when it's over the part of the border that's on top of the top-left box's content area. When you scroll over other parts of the border it doesn't scroll (the owning scroller).

That said, I do think 753124 is still the right issue to resolve this in. That issue is that when a scroller is composited, scrolling over a border doesn't cause scrolling but it does if it's non-composited. In this case, scrolling in that overlapping region forces the scrolls to be handed in the non-composited path so we end up scrolling from the border in that one place. Other regions are handled on the composited path. I don't think we can fix this in a general way without addressing 753124.

Rats! Sorry I didn't mention my retina screen macbook, probably wasted a bit of your time.

But yes, bokan@chromium.org, that is exactly the issue and thanks for clarifying! :D