Headless network inspector consistently returns "Invalid InterceptionId" and crashes Chrome
Reported by
a...@allotmentdigital.com,
Sep 19 2017
|
|||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Steps to reproduce the problem:
1. Use the Remote Debugging Protocol on headless and enable network request interception (continue all requests without modifying them, i.e. client.send('Network.continueInterceptedRequest',{interceptionId: params.interceptionId}) )
2. Navigate to https://www.merdeka.com/peristiwa/habib-rizieq-tegur-keras-presidium-alumni-212-karena-bela-hary-tanoe.html
What is the expected behavior?
Chrome should intercept requests and allow them to continue without throwing errors.
What went wrong?
One request on that page causes Chrome to throw an "Invalid InterceptionId" error (https://chromium.googlesource.com/chromium/src.git/+/refs/heads/lkcr/content/browser/devtools/devtools_url_request_interceptor.cc#121), even though all interceptionId's are directly passed to the continueInterceptedRequest event.
Node returns this error as:
(node:7600) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Invalid InterceptionId.
(node:7600) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Even when interceptions are always continued, this error seems to appear on a wide variety of unrelated webpages.
When several pages which cause this error are loaded in close succession (>100 errors), Chrome usually crashes. This is the behaviour on both 63.0.3213.3 and 62.0.3202.18
Did this work before? No
Does this work in other browsers? N/A
Chrome version: 63.0.3213.3 Channel: dev
OS Version: 17.04
Flash Version:
I'm using the NodeJS library chrome-remote-interface to open/manage the connection with CDP
,
Sep 21 2017
,
Sep 28 2017
Not related to Blink>Network, as that component is for network APIs implemented in Blink. Removing the Blink>Network component.
,
Oct 2 2017
,
Oct 3 2017
I have seen this happen before, usually because the renderer gets swapped out and the request is cancelled or resent. Most of the time you can ignore these errors, but we do not currently have a plan on how to fix this. Stay tuned.
,
Dec 13 2017
,
Dec 28
Closing this as WontFix since we can't reproduce this. There have been a lot of interception crashes fixes since this bug has been filed, so there's a good chance the cause has been fixed. If not, please file another with some details on how to reproduce the problem (stack traces or crash ids would also be helpful). Please note that you can get "Invalid interception id" on a previously valid id if the request got canceled by the renderer. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by brajkumar@chromium.org
, Sep 21 2017