New issue
Advanced search Search tips

Issue 659993 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Websocket onmessage callbacks are delayed when scrolling with mousewheel

Reported by tomfr...@gmail.com, Oct 27 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce the problem:
1. http://codepen.io/tomreay/pen/Gjzwvb
2. Wait for it to show "Connected", this might take 20-30 seconds the first time as the websocket server is hosted on Heroku and the instance goes to sleep
3. Scroll continuously using the mouse wheel in the div with scroll bars

What is the expected behavior?
The following should be printed:
Sending 1
1 response
Sending 2
2 response
Sending 3
3 response
Sending 4
4 response
...

What went wrong?
The following is printed
Sending 1
Sending 2
Sending 3
Sending 4
Sending 5
Sending 6
1 response
2 response
3 response
4 response
5 response
6 response

Did this work before? N/A 

Chrome version: 54.0.2840.71  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

Scrolling continuously is the easiest way to trigger it, the responses are all batched up and are completely blocked.  The same does not happen if you hold the down arrow key.

This works in Edge, IE and Firefox

After a 5-10 seconds it often seems to switch modes and works as expected.  This will sometimes but not always survive a refresh of the tab, but never survives the opening of a new incognito window.
 

Comment 1 by tkent@chromium.org, Oct 27 2016

Components: -Blink Blink>Scheduling Blink>Network>WebSockets
Status: Available (was: Unconfirmed)
Looks like this is caused by the intervention to block expensive tasks while scrolling. This is done to improve animation smoothness.

The way to avoid this is to reduce the amount of work you are doing in the message handler. Ideally it should take no more than few tens of milliseconds.

One thing we could do on the Chrome side is to treat WebSocket tasks separately from regular network tasks so that we could throttle the latter but not the former. We'll see if this is safe to do.

Comment 3 by tomfr...@gmail.com, Oct 31 2016

In the demo I provided the onmessage callback takes 0.5ms, hard to see how it could be any quicker!
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 31 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

Comment 5 by ricea@chromium.org, Nov 8 2017

Status: WontFix (was: Untriaged)
Tested on Linux and Windows 10. I had to use WebSocket server on localhost--the heroku one is no longer running.

I could not reproduce. Sent messages and responses were interleaved as expected.

Sign in to add a comment