Network.requestWillBeSent doesn't provide real requestId for iframes
Reported by
kdzwinel@gmail.com,
Dec 10
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36 Steps to reproduce the problem: In a headless chrome - Chromium 72.0.3618.0 (r609904): 1. Listen for `Network.requestWillBeSent` event 2. Load page with an iframe What is the expected behavior? `Network.requestWillBeSent` event should fire for an iframe request with a valid requestId (e.g. 1000018916.268). What went wrong? `Network.requestWillBeSent` is fired with requestId being equal to loaderId (e.g. requestId: '2438422FF66425A33F44979D4BE2C08D', loaderId: '2438422FF66425A33F44979D4BE2C08D'). Did this work before? No Chrome version: 71.0.3578.80 Channel: stable OS Version: OS X 10.14.2 Flash Version: If request for that iframe is blocked or fails, `Network.loadingFailed` returns a valid requestId. Having different requestIds for `Network.requestWillBeSent` and `Network.loadingFailed` makes it hard to make a connection between the two. Relevant code seems to be here: https://cs.chromium.org/chromium/src/content/browser/devtools/protocol/network_handler.cc?l=1660&rcl=0817cc924940c3ad27588db82f34dde7bac07007
,
Dec 10
,
Dec 11
Thanks for filing the issue... As per comment #0, the issue seems to be related to headless chrome. Hence requesting appropriate team to look into it and adding Proj-Headless label. Thanks..!
,
Dec 12
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by binghamj@google.com
, Dec 10