Thanks for filling the issue...

As per Comment #0 Assigning to dgozman@ and CC'ing the Dev pfeldman@ for their inputs.


Thanks..!

Thank you for filing this issue. This is indeed a problem, we'll work on fixing it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2731b569dbcc9d697916aaa76dbd7d12ad0e2265

commit 2731b569dbcc9d697916aaa76dbd7d12ad0e2265
Author: Dmitry Gozman <dgozman@chromium.org>
Date: Mon Sep 10 23:19:02 2018

[DevTools] Allow extensions to attach to OOPIFs

This reworks restricted sessions to have granular control over
specific permissions: target discovery, browser target, etc.

Target handler can now operate in autoAttachOnly mode which
is used for extensions. Previously we just banned target handler
from extension sessions, which broke OOPIF debugging for them.

Bug:  870314 
Change-Id: I0c3e8860aca547bb631e2a9615e58ac33465d88e
Reviewed-on: https://chromium-review.googlesource.com/1212089
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590112}
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/devtools/devtools_sanity_browsertest.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/devtools/devtools_ui_bindings.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/devtools/devtools_window.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/devtools/devtools_window.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/devtools/devtools_window_testing.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/devtools/devtools_window_testing.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/extensions/api/debugger/debugger_api.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/browser/extensions/api/debugger/debugger_apitest.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/test/data/extensions/api_test/debugger/background.js
[add] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/test/data/extensions/api_test/debugger/oopif.html
[add] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/chrome/test/data/extensions/api_test/debugger/oopif_frame.html
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/browser_devtools_agent_host.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/devtools_agent_host_impl.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/devtools_agent_host_impl.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/devtools_http_handler.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/devtools_session.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/devtools_session.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/forwarding_agent_host.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/forwarding_agent_host.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/protocol/target_handler.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/protocol/target_handler.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/browser/devtools/render_frame_devtools_agent_host.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/public/browser/devtools_agent_host.h
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/public/browser/devtools_agent_host_client.cc
[modify] https://crrev.com/2731b569dbcc9d697916aaa76dbd7d12ad0e2265/content/public/browser/devtools_agent_host_client.h

This should be fixed in tomorrow's Chrome Canary. Could you please verify from your end?

Thanks for the update and fix. I'll try it out tomorrow.

I've run some tests and the TARGET.setAutoAttach method does now result in Target.attachedToTarget events for iframes. However, the debugger doesn't actually appeared to be attached to the new target.

In my tests I used chrome.debugger.attach() on the tabId and then sent the TARGET.setAutoAttach command.

If I attempt to turn on network events for the new target (iframe) in the  Target.attachedToTarget event using something like this:

var newTargetId = params.params.targetInfo.targetId;
chrome.debugger.sendCommand({"targetId": newTargetId }, "NETWORK.enable", ...)

I get an error in the callback of the sendCommand:

"Debugger is not attached to the target with id: <newTargetId>."

I tried manually attaching first using:

chrome.debugger.attach({"targetId": newTargetId }, "1.2", ...)

This works and the NETWORK.enable succeeds if the iframe based page is already loaded in the tab.

However, if I attempt this during the loading of the page the attach fails with:

"Cannot access contents of url "". Extension manifest must request permission to access this host."

Is this related to the fact that during the page load the Target.attachedToTarget event has a url of ""?

I assume that a manual attach of the debugger shouldn't be necessary when auto attach is enabled. Or have I misunderstood the API?

> chrome.debugger.sendCommand({"targetId": newTargetId }, "NETWORK.enable", ...)

Once you are using Target domain, you shouldn't be using that targetId as a mean of debuggee. I know it's not clear in the docs, sorry for confusion. The proper way would be:

var message = {id: 1, method: 'Network.enable', params: {...}};
chrome.debugger.sendCommand(originalDebuggee, 'Target.sendMessageToTarget', {targetId: newTargetId, message: JSON.stringify(message)});

See documentation for the Target domain here [1]. When connected to a "child" target discovered through Target domain, use Target domain's methods to communicate with it.

[1] https://chromedevtools.github.io/devtools-protocol/tot/Target#method-sendMessageToTarget

Thanks for the clarification and the sample code. I can now confirm that the network events are being successfully delivered from the nested iFrame through the Target.receivedMessageFromTarget event.

I can provide more detail in about a week or so once we've added the code to handle targetIds and the use of Target.sendMessageToTarget where required.

In the meantime could you answer the following queries:

1) Is autoattach enabled for all new nested targets as well? i.e. would an iframe inside an iframe get automatically attached? Or would I need to send a setAutoAttach message for each new target notification?

2) I'm currently using a value of waitForDebuggerOnStart: false in the setAutoAttach message. Does this mean my handler could miss network events? I send a Network.Enable as soon as the Target.attachedToTarget event is received but could network events be missed? Would it be better to set waitForDebuggerOnStart to true initially and then call Runtime.runIfWaitingForDebugger after sending Network.Enable?

3) The docs show the targetID parameter as deprecated in the Target.sendMessageToTarget message. Is that correct? Or can it be safely used as per your sample code above?

> 1) Is autoattach enabled for all new nested targets as well? i.e. would an iframe inside an iframe get automatically attached? Or would I need to send a > setAutoAttach message for each new target notification?

You need to do it recursively.

> 2) I'm currently using a value of waitForDebuggerOnStart: false in the setAutoAttach message. Does this mean my handler could miss network events? I
> send a Network.Enable as soon as the Target.attachedToTarget event is received but could network events be missed? Would it be better to set
> waitForDebuggerOnStart to true initially and then call Runtime.runIfWaitingForDebugger after sending Network.Enable?

Pausing and resuming is the right thing to do. Glad you figured it out.

> 3) The docs show the targetID parameter as deprecated in the Target.sendMessageToTarget message. Is that correct? Or can it be safely used as per your
> sample code above?

It is deprecated, using |sessionID| is safer in the long run. It is available in all the same methods alongside the targetID. That said, targetID is not going away soon.

It's working as described. I can now successfully record network events from iframes and also iframes nested within iframes.

Thanks again for the fix and your help with the API.

Unfortunately, I wasn't correctly testing the nested iframe case because the page and first iframe used the same host name.

I've now set up this URL to have two levels of iframes from different host names which cause site isolation to create separate targets:

https://sslrobottest.azurewebsites.net/nested-iframe.htm

My extension code no longer successfully auto attaches to targets inside the first iframe. I was attemptting to do this by simply sending the Target.setAutoAttach to the top level tab target with the session id of the new nested target. This results in the error:

"No session with given id"

Do I need to nest the Target.setAutoAttach message within Target.sendCommandToTarget messages for each nesting level? 

I was hoping that the experimental flatten parameter on the Target.setAutoAttach message would allow me to avoid that complexity in my code. When I tried setting flatten to true I get a crash in Chrome Canary 71.0.3562.0 

I have attached .dmp files from the following crash reports as there doesn't seem to be a way to send them automatically from Chrome Canary.

Local Crash ID dfa734e9-99c1-4867-af85-69a7d5567b57
Local Crash ID e21c4d3a-3b70-408e-8f68-ad45c51e4c37
Local Crash ID 45265b24-3795-43e9-a092-e51bdf884a48

Deleted: dfa734e9-99c1-4867-af85-69a7d5567b57.dmp 1.9 MB

dfa734e9-99c1-4867-af85-69a7d5567b57.dmp 1.9 MB Download

Deleted: e21c4d3a-3b70-408e-8f68-ad45c51e4c37.dmp 2.0 MB

e21c4d3a-3b70-408e-8f68-ad45c51e4c37.dmp 2.0 MB Download

Deleted: 45265b24-3795-43e9-a092-e51bdf884a48.dmp 1.9 MB

45265b24-3795-43e9-a092-e51bdf884a48.dmp 1.9 MB Download

Thank you for trying this out! You indeed have to wrap all the inner target's commands with Target.sendCommandToTarget if not using "flatten". I'd suggest to avoid flatten for now, since it's experimental, and we cannot guarantee things will continue to work. Once we finish our work on flat protocol, we'll update the documentation with instructions on how to use it.

As for the crash, could you please go to chrome://crashes and copy the "Uploaded Crash Report ID" here? That way I will be able to fix it :)

The wrapping/unwrapping of the target commands is working successfully and delivering network events as expected for deeply nested iframes. Thanks for your help.

I wasn't able to upload the crash report from the Canary build but I did reproduce it in the Dev Channel. The details are:

Uploaded Crash Report ID a5e8d02b76cd431d (Local Crash ID: b7be6bcc-5786-4069-aef3-f2b21bf44376)
Crash report captured on Monday, October 1, 2018 at 3:22:10 PM, uploaded on Monday, October 1, 2018 at 3:22:17 PM

I entered some details in issue 890760