Thanks for filing the issue...

Tried to reproduce the issue on reported chrome version 70.0.3538.110 using Mac 10.14.0. Attaching screen-cast for reference.
Steps: 
-----
1. Launched reported chrome 
2. Navigated the URL "https://codepen.io/xianshenglu/pen/wRWrdX"
3. In chrome scrolled on the gray area observed > scrolling contentious
4. In Firefox scrolled on the gray area observed > scrolling stops when mouse entered into pink area   
As we are able to scroll down on gray area  

@Reporter: Could you please check the attached screencast and let us know if we missed anything form our end and verify latest chrome stable 71.0.3578.98, you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ". Let us know whether issue still persists.

Thanks.!

Deleted: 916007.mp4 2.3 MB

	916007.mp4 2.3 MB View Download

See the video I attached. The key is:

1. I do the mousewheel job in pink area
2. I stopped the mousewheel job.
3. I move the mouse to the grey area.
4. The document scrolled. This behavior is not expected because I didn't do the mousewheel job when and after I moved the mouse to the grey area. I only did it in the pink area. And I used event.preventDefault() in the pink area. 

Deleted: 137c896dd8d6a798e46a80acda9f6bd0.mp4 628 KB

	137c896dd8d6a798e46a80acda9f6bd0.mp4 628 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

you can try this demo, https://codepen.io/xianshenglu/pen/bORKMN?editors=1111

With a screen like the attached files, easy to find this problem.

The log will prove that whether you did the mousewheel job after you left the pink area.

Deleted: 截图20181226131708.png 60.6 KB

	截图20181226131708.png 60.6 KB View Download

Able to reproduce the issue on reported chrome version #70.0.3538.110, latest chrome version #71.0.3578.98 and latest chrome #73.0.3664.3 as per comment#5 using Windows 10, Ubuntu 17.10 and Mac OS 10.13.6.

The behaviour is seen from M-60(#60.0.3112.113), considering it as non-regression hence marking it as untriaged and requesting someone from the dev team to look into the issue.
Thanks.!

I don't seem to reproduce it with normal mouse we have that we have. I wonder if that is related to the magic mouse or not. reporter can you confirm that? Does it also happen with trackpad scrolling?
cc'ing Sahel as she might has some ideas about what's going on.

Some mouse devices including the magic mouse will keep sending (inertial) wheel events for a while after the user has stopped scrolling. That's why more wheel events are received after the move. To confirm that mouse wheel events are arrived after mouse move could you please record a tracing using the following instructions and attack it here (please make sure that the input category is selected):
https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

The scroll sequence for mouse wheel breaks when the cursor moves more than 10 pixel. Even though prevent default is called in the pink area, when the mouse is moved to the white area the rest of the wheel events (those which arrive after the user has stopped scrolling) will be sent to the new target under the cursor which correctly causes the parent element to scroll down.

I don't think DOM-team has any connection to this bug.

I can't reproduce it in win7 chrome. I found this bug in the Mac computer in my company. But I resigned at Christmas. It's not easy for me to reproduce it or provide other things. The previous reproduction I got is from my friend's Mac. I will try to  record a trace if my friend is online. 

Sure. A trace would help us about this. 

Sorry for delay. Hope the trace help.

Deleted: trace_bugger.json.gz 6.8 MB

trace_bugger.json.gz 6.8 MB Download

Deleted: trace_bug.json.gz 4.8 MB

trace_bug.json.gz 4.8 MB Download