I forgot the most important thing. Both examples shown above are actively trying to prevent the propagation of the wheel event, so that when the user scrolls down and reaches the bottom, the parent element remains static.

This is likely happening because in dev channel the wheel scrolls are being handled on the compositor thread at the same time the next wheel event is being processed.

Great to know. Thank you.

I can reproduce this as well. #2 is correct that this is an artifact for handling wheel scrolls on compositor. 

In particular, the scroll offset is not updated on main thread so the handler logic assumes that the wheel event can be handled without overscrolling but in reality on the compositor thread we will overscroll and bubble to scroll the parent.

Perhaps this becomes a non-issue once we modify wheel scroll behaviour to latch: http://crbug.com/526463

The logic is trying to prevent scroll bubbling, this becomes unnecessary if we ended up having a method to control bubbling behaviour:  http://crbug.com/162179 

I am not sure how many people are using such a UI pattern on the web. Perhaps a short-term fix may be for applications to take into account the inflight wheel-delta since last scroll in the calculation.

We shouldn't block this on latching, as latching is still a ways out.

>I am not sure how many people are using such a UI pattern on the web. Perhaps a short-term fix may be for applications to take into account the inflight wheel-delta since last scroll in the calculation.

Do you mean using e.wheelDelta instead of e.deltaY? I tried to change it in the plnkr above, but doesn't seem to work on its own.

Assigned to dtapuska@, as this is due to wheel gestures.

I'm removing the block on this because wheel latching is still a ways out, and we probably want a shorter term fix here.

Over to sahel@ blocking this on latching since it is quite soon.

Wheel scroll latching which is enabled by default since M65 solves this issue.