New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 165 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

issue 563644
issue 627188

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Issue 423246: websockets not included when using connection throttling

Reported by, Oct 14 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36

Steps to reproduce the problem:
1. use devtools in device mode
2. set network throttling
3. websocket requests are not throttled

What is the expected behavior?
websocket requests should be subject to the same latency and speed throttling as http requests

What went wrong?
http requests are throttled correctly, websocket requests still respond instantly with no latency problems

Did this work before? No 

Chrome version: 38.0.2125.101  Channel: stable
OS Version: 6.3
Flash Version: Shockwave Flash 15.0 r0

Comment 1 by, Oct 14 2014


Comment 2 by, Oct 14 2014

Status: Assigned

Comment 3 by, Nov 26 2014

 Issue 436559  has been merged into this issue.

Comment 4 by, Nov 28 2014

 Issue 437287  has been merged into this issue.

Comment 5 by, Jan 21 2015

 Issue 450248  has been merged into this issue.

Comment 6 by, Mar 26 2015

Labels: -OS-Windows OS-All
 Bug 446909  seems to be right along the same lines here. I think we could merge these two together as "Devtools: Network Emulation has no effect in Websockets" for tracking. Not sure if you want to track each issue specifically or make a meta-bug to help for searchability.

Comment 7 by, Sep 23 2015

Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!


Comment 8 by, Nov 15 2015

 Issue 553933  has been merged into this issue.

Comment 9 by, Nov 15 2015


Comment 10 by, Nov 30 2015

Blocking: chromium:563644

Comment 11 by, Dec 18 2015

Labels: -Pri-2 Pri-1 Cr-Platform-DevTools-Network

Comment 12 by, Feb 16 2016

 Issue 556474  has been merged into this issue.

Comment 13 by, Feb 16 2016

 Issue 587134  has been merged into this issue.

Comment 14 by, Apr 6 2016

Issue 600788 has been merged into this issue.

Comment 15 by, Apr 13 2016


Comment 16 by, May 19 2016

Labels: network-throttling-issues

Comment 17 by, May 27 2016

 Issue 615335  has been merged into this issue.

Comment 18 by, Jun 29 2016

Any update on this? Still having the same issue on 51.0.2704.84. Thanks

Comment 19 by, Jun 29 2016

There has been some talk about fixing this, but there's some underlying problems. Right now we are wrapping Fetch with a throttling class, but Websockets, WebRTC and a few other types of requests do not go through Fetch so they do not get throttled. This item is not far from the top of my list. There have been a few design docs proposed but no elegant solution yet.

Comment 20 by, Dec 6 2016

Is there any estimated time or solution?

Comment 21 by, Jan 23 2017

Ideally throttling would happen at the socket level so it would be protocol agnostic.

Failing that, the correct way would be to implement a subclass of net::WebSocketStream which delays frames and interposes itself behind WebSocketBasicStream.

Comment 22 by, Feb 28 2017

Hey, any update on this?

Comment 23 by, Feb 28 2017

I ran into this when testing offline behaviour. Would it be an easy step forward to at least disable the connection when in "Offline" mode and handle throttling in the next step if it's more complex?

Comment 24 Deleted

Comment 25 by, Mar 1 2017

I actually tested Firefox “Work Offline” and it also doesn’t block WS so it has the same unexpected behaviour.

Comment 26 by, Mar 2 2017

I am on Firefox 51.0.1, Mac. "Work Offline" blocks WS for me.

Comment 27 by, Mar 11 2017

Sadly there is still no major update on this. I spoke with a few team members across chrome during our last Chrome Loading Summit in early February and to implement this for websockets requires quite a bit of refactoring and overhead to support this currently. This does not mean we will not fix this, it simply means it's not a priority yet. There has been a bit of work on other types of throttling in chrome and with any luck we might be able to get this done in a way that multiple teams would be a client of it.

Comment 28 by, Aug 4 2017

Agreed. I can see why throttling WS and WebRTC connections would be difficult, but completely cutting them off shouldn't be that hard (although I don't know much about Chrome internals, so I can't say).

Comment 29 by, Aug 19 2017

 Issue 756647  has been merged into this issue.

Comment 30 by, Sep 21 2017

Blocking: 627188

Comment 31 by, Oct 18 2017

navigator.connection (Network Information API)(Editor's Draft) also needs to be updated when throttling is enabled. On Chrome 62 it will return a normal online connection object even if throttling is set to Offline.
Screen Shot 2017-10-18 at 1.20.09 PM.png
73.4 KB View Download

Comment 32 by, Oct 19 2017

#c31, that's slightly different than this ticket. 
I filed a new ticket as there was a regression. See  issue 776229 .
Regardless, thanks for the heads up.

Comment 33 by, Nov 9 2017

navigator.onLine working fine but I am getting every incoming/outgoing WebSockets

Comment 34 by, Dec 13 2017


Comment 35 by, Oct 31

Bump. 140 Stars, many issues reported and merged into this, no activity in almost a year, no resolution after 4 years.

Comment 36 by, Nov 9


Comment 37 by, Nov 9

 Issue 627188  has been merged into this issue.

Comment 38 by, Nov 9

 Issue 824796  has been merged into this issue.

Comment 39 by, Jan 10

Seems like there's been a regression - connection throttling no longer works for Fetch requests (with streaming response.body) on current stable Chrome 71.
Pretty sure it used to throttle Fetch as well, not sure when it broke.

Sign in to add a comment