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

Issue 845134 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Network.disable is not sent when network inspection is turned off

Reported by ing...@cloudflare.com, May 21 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0

Steps to reproduce the problem:
1. Open Network tab in devtools (with recording on, as it is by default).
2. Open Protocol Inspector.
3. Disable network logging.

What is the expected behavior?
Network.disable CDP command is sent to the inspector server so that it can stop intercepting requests, storing responses for potential Network.getResponseBody calls and so on.

What went wrong?
Network.disable is not sent so backend has no way of knowing that inspector frontend is no longer interested in / subscribed to Network events and that there is no point in intercepting and storing the corresponding data.

Did this work before? N/A 

Chrome version: 68.0.3436.0  Channel: canary
OS Version: OS X 10.13
Flash Version:
 
This is by design - we keep monitoring to continue receive notifications about requests in flight. Why is this a problem?
Mostly just a performance concern (especially memory one, since getResponseBody requires keeping body pretty much indefinitely until the client disconnects) for non-Chrome backends. Can you elaborate please what's the point to continue monitoring if client is not subscribed to these new requests and won't show them anyway?
Labels: Needs-Triage-M68
Cc: sindhu.chelamcherla@chromium.org dgozman@chromium.org
Labels: Triaged-ET
As per comment#1 cc'ing  dgozman@ for further inputs on this. Could you please check comment#2 and help in triaging this.

Thanks!
Status: WontFix (was: Unconfirmed)
- If the request was started before user pressed "stop", we keep getting updates for it and update that request in UI (e.g. showing new timing).
- We continue to apply any modifications even when user is not recording, e.g. user agent override, interceptions, url blocking, throttling, etc.

We can make storing requests data optional during this time, but it never was a concern, and it will require a command separate from disable.

Sign in to add a comment