Debugger, target, autoAttach questions

357 views
Skip to first unread message

Tomislav Zorčec

unread,
Jan 25, 2021, 5:52:46 AM1/25/21
to chrome-debugging-protocol
Hi,

  I'm a bit confused about what exactly is the target in the context of https://chromedevtools.github.io/devtools-protocol/tot/Target/

* What exactly do you consider to be a target?
* Where is setAutoAttach trying to attach to exactly?
* What could be the reason of getting "{"code":-32000,"message":"Not allowed"}" when sending "Target.setDiscoverTargets" command.  

To give you a bit of context, I'm trying to find a way to reliably attach the debugger very early to the new tabs, before the navigation starts to be able to start emulation (set user agent for the 1st top document request), capture all the requests, etc.

* Is there an official way how this can be done?

Thank you for your time, Tomislav
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Tomislav Zorčec

unread,
Jan 25, 2021, 6:46:36 AM1/25/21
to chrome-debugging-protocol
I'm trying to do this from the chromium extension.
I attached an extension example.

What the code is doing:
* Opening a new tab (that loads an internal extension page)
* Attaching chrome.debugger on it
* Sending "Target.setAutoAttach" & "Target.setDiscoverTargets"

On the internal page I click on the "What is my UA (_blank)" that will show you the emulated UA. 
(if it would work it would be; "debugger is attached")

I assume that this also might be the limitation of the chromium API, not the devTools protocol, but even if that is the case I would assume that the mentioned commands should work, or to get some kind of an exlination for it.

(I cannot attach .zip, so I attached only the background logic, for the full extension code please let me know where would you like to have to uploaded)
background.js.txt

Andrey Kosyakov

unread,
Jan 25, 2021, 8:25:42 PM1/25/21
to Tomislav Zorčec, chrome-debugging-protocol
Hi Tomislav.

On Mon, Jan 25, 2021 at 2:52 AM Tomislav Zorčec <zor...@gmail.com> wrote:
  I'm a bit confused about what exactly is the target in the context of https://chromedevtools.github.io/devtools-protocol/tot/Target/

* What exactly do you consider to be a target?

From the point of view of DevTools protocol, a target is a single end-point a client is talking to. In chrome, this is either a set of frames within the same renderer (i.e. a loca tree) or a single worker (of any type) or worklet. There's also "Browser" target that handles some commands with browser-wide scope, but extensions can't attach to it.
 
* Where is setAutoAttach trying to attach to exactly?

setAutoAttach attaches to all targets considered related to the frame you're issuing this command to. "Related" implies either an iframe that belongs to the same page (which will be a separate target iff it is in a different process) or a worker (I believe that right now this will only work for a service worker).
 
* What could be the reason of getting "{"code":-32000,"message":"Not allowed"}" when sending "Target.setDiscoverTargets" command.  

That's because you're doing it from an extension. Extensions can't discover arbitrary targets for security reasons, so we only allow auto-attaching to "related" targets.

To give you a bit of context, I'm trying to find a way to reliably attach the debugger very early to the new tabs, before the navigation starts to be able to start emulation (set user agent for the 1st top document request), capture all the requests, etc.

* Is there an official way how this can be done?

If you want it to be early enough, setAutoAttach with {autoAttach: true, waitForDebuggerOnStart: true, flatten: true} is the only way. However, you won't be able to do that from an extension, because in order for setAutoAttach to have effect on all tabs, it needs to happen on the browser target. If your environment allows for it, I would recommend using an external protocol client (e.g. Puppeteer) to drive the browser.

Best regards,
Andrey.



Tomislav Zorčec

unread,
Jan 26, 2021, 12:31:55 AM1/26/21
to chrome-debugging-protocol
Thank you Andrey for the helpful answers. This perfectly covers all I wanted to know.

We are developing a synthetic monitoring solution (a Puppeteer in a browser where the extension is the driver); we also offer browser clickpath recording where we do not have any control over the environment. So the external protocol client is not an option for us.
Our solution will not fully survive MV3, and we are trying to find out alternative ways to support the same set of features to our end users.
I might have a possible solution, but it is not ideal ("hacky" solution of blocking new tabs by redirecting them and navigating to the target URL once we are ready), so I was hoping "setAutoAttach" might work for us.

Pablo Menichelli

unread,
Mar 31, 2022, 3:50:15 PM3/31/22
to chrome-debugging-protocol
This was very useful info, I had the same problem of getting this "Not allowed" error. 

Is there a way to know which commands are available to an extension? I'd like to attach the debugger only to a specific worker that I know exists on a particular website.

Pavlo Manko

unread,
Aug 22, 2023, 12:03:19 PM8/22/23
to chrome-debugging-protocol
Hi Andrey,
You said that extension cannot attach to "Browser" target, but I noticed there is Target.attachToBrowserTarget command:
Is it something that we can use to attach to new browser tabs?
Reply all
Reply to author
Forward
0 new messages