New issue
Advanced search Search tips

Issue 866939 link

Starred by 1 user
Status: WontFix
Owner:
pfeldman@chromium.org
Closed: Jul 26
Cc:
caseq@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Network events missing when using chrome.debugger extension API with iframes

Reported by supp...@neumetrix.com, Jul 24 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. Use the modified version of the live headers extension from the chromium src tree (There's an extra few lines added to display the loadingFinished and loadingFailed events)
2. Open https://sslrobottest.azurewebsites.net/iframe.htm
3. Open the Live Headers extension using green icon 
4. Refresh the iframe page

What is the expected behavior?
The Live Headers window should show the requests for iframe.htm and all the requests to build https://zlib.net (the embedded iframe URL). This is what you see in Devtools=>Network.

Also, each request should be terminated with either a loadingFinished or loadingFailed event.

What went wrong?
The request for https://zlib.net does receive a loadingFinished event so it looks like it never terminates.

Also, none of the embedded resources for the zlib.net page are reported with events through the chrome.debugger interface.

These issues prevent the effective use of chrome.debugger when the page being debugger contains an iframe.

Did this work before? N/A 

Chrome version: 67.0.3396.99  Channel: stable
OS Version: 10.0
Flash Version:
modified-live-headers.zip
3.4 KB Download

Comment 1 by supp...@neumetrix.com, Jul 24 

The above should have read "The request for https://zlib.net **does not** receive a loadingFinished event"

The URL https://sslrobottest.azurewebsites.net/iframe.htm just returns a simple HTML page with an embedded iframe like this:

<!DOCTYPE html>
<html>
<body>

    <iframe src="https://zlib.net/">
        
    </iframe>

</body>
</html>

I have also attached screenshots of the Live Headers and Devtools outputs.
missing-loadingFinished-event.png
73.0 KB View Download
missing-requests.png
59.8 KB View Download

Comment 2 by krajshree@chromium.org, Jul 25

Labels: Needs-Triage-M67

Comment 3 by caseq@google.com, Jul 26

Cc: caseq@chromium.org
Components: -Platform>DevTools Platform>DevTools>Platform
Owner: pfeldman@chromium.org
Status: WontFix (was: Unconfirmed)
This is a side effect of OOPIF, the extensions likely needs a fix to support DevTools target model in case of OOPIF (consider chrome://flags/#site-isolation-trial-opt-out as a workaround meanwhile).

What happens there is that for cross-origin frames, a new DevTools target (along with the network agent) is created for the local root in a new renderer, and once the iframe navigation is committed, the network events are reported from the new target. The extension needs to attach to the new target, enable network agent and monitor events there similarly to how DevTools front-end does.

Comment 4 by supp...@neumetrix.com, Jul 26 

Thank you for the update. The site-isolation-trial-opt-out flag does provide the expected behavior.

How would an extension attach to the new target once the iframe is committed? The Debuggee parameter of chrome.debugger.attach can contain a tabid, extensionid or targetid. Presumably, the targetid would need to be used. How would the extension get the targetid of the new target created for the iframe?
►

Sign in to add a comment