Bill McCloskey [inactive unless it's an emergency] (:billm) Reporter
	Description • 9 years ago

I probably have the wrong lingo here, but the problem is pretty simple. Right now, a tool like the console or the debugger can only debug a single process, be it the chrome process or a content process. This causes problems in two places:

1. For the Browser Toolbox, we'd like to be able to debug chrome code in both the main process and all the content processes. We've worked around this by creating a separate tool, the "Browser Content Toolbox", that arbitrarily chooses a content process to debug. This will never work for multiple content processes, though.

2. Add-ons run code in both the main process and content processes. Our add-on debugging UI (when you hit "Debug" in about:addons) makes it look like you can debug all the add-on code in one tool, but it's actually only debugging the main process. As more add-on code runs in the content processes, this is becoming more of a problem, particularly for the new extension API.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1175770#c11 for Alexandre's comments on this.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 1 • 9 years ago

Switching from inspecting one process to inspecting another is probably not too hard. Retrofitting support for concurrent and parallel debugging of multiple processes at the same time is going to be very hard.

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 2 • 9 years ago

This discussion is certainly relevant to Eddy, who is working on support for debugging workers.

	Gabor Krizsanits (INACTIVE)
	Comment 3 • 9 years ago

(In reply to Nick Fitzgerald [:fitzgen][:nf] from comment #2)
> This discussion is certainly relevant to Eddy, who is working on support for
> debugging workers.

Is there anyone else who grocks this? Eddy won't be available for a few more weeks...

	Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]
	Comment 4 • 9 years ago

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #3)
> (In reply to Nick Fitzgerald [:fitzgen][:nf] from comment #2)
> > This discussion is certainly relevant to Eddy, who is working on support for
> > debugging workers.
> 
> Is there anyone else who grocks this? Eddy won't be available for a few more
> weeks...

Someone who groks the worker debugging stuff he is working on? Or...?

	Alexandre Poirot [:ochameau]
	Comment 5 • 9 years ago

It may be easier to display add-on ressources within the page toolbox (that already targets the content process) rather than having all addons resources (from distinct processes) to appear only within an add-on toolbox.
I think chrome devtools are doing that.

Same thing applies to the browser content toolbox... In many cases (all cases where you don't have to close the tab where you opened the tools) it would be much much easier to display frame script and other chrome resources within regular page toolbox. I got negative traction from devtools folks when I suggested doing that.

	Andy McKay
	Comment 6 • 8 years ago

Luca, is this related to the stuff you are working on in this quarter?

	Luca Greco [:rpl] [:luca] [:lgreco]
	Comment 7 • 8 years ago

This is not related to the currently planned changes.

During the Firefox 48 cycle we've already added what Alex describes in Comment 5:

the WebExtensions content scripts are debuggable from the tab developer toolbox, alongside the sources of the web page that the content script is associated, like it happens for Chrome and Firefox Addon SDK content scripts, and so it should not be surprising for the addon developers.

The devtools are currently designed to connect to a single process running its own DebuggingServer, and so the above strategy is the most reasonable way to achieve the full debuggability of content scripts without the need of applying big changes to the related devtools components.

NOTE: once the addons contexts will be moved into another process, we should be able to still use the current approach as long as all the addons contexts (besides the content scripts as described above) will run in the same process.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 8 • 6 years ago

We plan to achieve this as part of our support for Site Isolation in DevTools.