Here's an example showing the difference between composited and non-composited scrollers: http://output.jsbin.com/ceyozeh/quiet

This only affects Chrome.

iOS Safari also has the exact same inconsistency when off-thread scrolling is activated via "-webkit-overflow-scrolling: touch".  Tested with http://jsbin.com/kayutiv/ on my iPod touch.  Desktop Safari and Firefox consistently use the main-thread style.  I'll try to remember to check Edge when I get back to my Windows machine.

This question is related to the separation of graphics data structures from hit-testing data structures on the impl thread.  If we decide to change impl-thread behavior to match main thread, it should be blocked on that refactoring.  +cc rjkroege on that.

Since scrollbars are drawn inside the border box, it seems strange to me that mouse wheels outside the inner edge of the border box would produce scrolling. Perhaps we should just fix main-thread scrolling to behave like CC?

In any case, this has been around forever without any complaint so I'm not sure its worth significant effort to fix in the current form. With slimming paint, CC should be able to tell that the hit display item is part of the border/background of the scrolling Element, right? It should be easy enough to decide whether the border should cause scrolling or not in that case.

In SPv2 we are going to generate hit-testing layers that doesn't draw, but added for the sole purpose of handling scroll events. We found this bug when we tried to figure out what size the hit-testing layer should be. (Implies we can easily implement either behavior.)

+1 IMO the composited behavior, i.e. not including the border, is more intuitive. I only worry that the spec might require otherwise. 

The main thread behavior also kind of makes sense because DOM event handling is element-based. The sequence of event roughly goes like this: touch down event --> hit testing --> subsequent event pinned to the element --> touch move event --> deliver to the same element --> no touch handler, default converts to drag gesture --> deliver to the same element --> no gesture handler, default converts to scroll --> deliver to the same element --> scroll

Because the hit-testing was done before we even know it eventually will become a scroll, and once converted to a scroll, we no longer have the context to determine whether the scroll was applied on the border.

I tested Edge on http://jsbin.com/kayutiv/ on Surface Pro: it behaves the same as Firefox.

> (Implies we can easily implement either behavior.)

If it's perfectly easy and clean then I think we should go with the spec behavior.  Working in all browsers the exact same way is more important to developers than "intuitive".  That leaves iOS Safari with "-webkit-overflow-scrolling: touch" as the outlier, but they have that property specifically because they want to ignore interop.

However, I also think this issue is minor enough that it's not worth paying more than an epsilon of implementation pain or architectural cruft to meet the spec, so it had better be *really* clean.

 Issue 837877  has been merged into this issue.