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
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Blocking:
issue 563644
issue 627188


Show other hotlists

Hotlists containing this issue:
Nice-to-haves-for-Project-V


Sign in to add a comment
link

Issue 423246: websockets not included when using connection throttling

Reported by m...@proctorio.com, 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 pkin...@gmail.com, Oct 14 2014

Cc: paulir...@chromium.org

Comment 2 by eustas@chromium.org, Oct 14 2014

Owner: eustas@chromium.org
Status: Assigned

Comment 3 by eustas@chromium.org, Nov 26 2014

 Issue 436559  has been merged into this issue.

Comment 4 by eustas@chromium.org, Nov 28 2014

 Issue 437287  has been merged into this issue.

Comment 5 by ricea@chromium.org, Jan 21 2015

 Issue 450248  has been merged into this issue.

Comment 6 by jonathan...@gmail.com, Mar 26 2015

Cc: jonathan.garbee@chromium.org
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 lafo...@chromium.org, 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!

-Anthony

Comment 8 by paulir...@chromium.org, Nov 15 2015

 Issue 553933  has been merged into this issue.

Comment 9 by paulir...@chromium.org, Nov 15 2015

Owner: dgozman@chromium.org

Comment 10 by paulir...@chromium.org, Nov 30 2015

Blocking: chromium:563644

Comment 11 by dgozman@chromium.org, Dec 18 2015

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

Comment 12 by jonathan...@gmail.com, Feb 16 2016

 Issue 556474  has been merged into this issue.

Comment 13 by jonathan...@gmail.com, Feb 16 2016

 Issue 587134  has been merged into this issue.

Comment 14 by michae...@chromium.org, Apr 6 2016

Issue 600788 has been merged into this issue.

Comment 15 by allada@chromium.org, Apr 13 2016

Owner: allada@chromium.org

Comment 16 by allada@chromium.org, May 19 2016

Labels: network-throttling-issues

Comment 17 by allada@chromium.org, May 27 2016

Cc: allada@chromium.org
 Issue 615335  has been merged into this issue.

Comment 18 by petdar...@gmail.com, Jun 29 2016

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

Comment 19 by allada@chromium.org, 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 philipp....@otto.de, Dec 6 2016

Is there any estimated time or solution?

Comment 21 by ricea@chromium.org, 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 sha...@peer5.com, Feb 28 2017

Hey, any update on this?

Comment 23 by amatt...@reaktor.fi, 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 amatt...@reaktor.fi, 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 starbala...@gmail.com, Mar 2 2017

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

Comment 27 by allada@chromium.org, 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 totallyu...@gmail.com, 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 l...@chromium.org, Aug 19 2017

Cc: jmukthavaram@chromium.org
 Issue 756647  has been merged into this issue.

Comment 30 by allada@chromium.org, Sep 21 2017

Blocking: 627188

Comment 31 by fosspr...@gmail.com, 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 paulir...@chromium.org, 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 itsaz...@gmail.com, Nov 9 2017

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

Comment 34 by pfeldman@chromium.org, Dec 13 2017

Owner: caseq@chromium.org

Comment 35 by xander.d...@gmail.com, 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 jarhar@chromium.org, Nov 9

Owner: jarhar@chromium.org

Comment 37 by jarhar@chromium.org, Nov 9

Cc: divya.pa...@techmahindra.com jarhar@chromium.org caseq@chromium.org
 Issue 627188  has been merged into this issue.

Comment 38 by jarhar@chromium.org, Nov 9

 Issue 824796  has been merged into this issue.

Comment 39 by to...@helloeko.com, 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