Closed Bug 1189556 Opened 4 years ago Closed 13 days ago
A single devtool must be able to manipulate actors in multiple processes
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.
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.
This discussion is certainly relevant to Eddy, who is working on support for debugging workers.
(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...
4 years ago
Priority: -- → P2
(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...?
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.
Luca, is this related to the stuff you are working on in this quarter?
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.
We plan to achieve this as part of our support for Site Isolation in DevTools.
Depends on: 1439048
Status: NEW → RESOLVED
Closed: 13 days ago
Resolution: --- → DUPLICATE
Duplicate of bug: dt-fission
You need to log in before you can comment on or make changes to this bug.