Closed Bug 1427997 Opened 7 years ago Closed 3 years ago

Allow to debug processes in about:debugging

Categories

(DevTools :: about:debugging, enhancement, P3)

58 Branch
enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jdescottes, Unassigned)

References

Details

Attachments

(2 files)

One of the features currently available in the connect screen is to be able to connect to the main process of a remote instance of Firefox. This feature is currently not available in about:debugging. This requirement was also mentioned in Bug 1420231.
Blocks: 1243329
See Also: → 1420231
I have a first basic implementation using our current process actor + about:devtools-toolbox. This seems to work reasonably well, including when connected to a remote instance. Here are a few questions: - are we getting all the processes that can be interesting debug targets? Are there other processes used by FF beyond the parent and content processes? - our processes lack metadata, we only have the id (which is the index of the process) and assume that id==0 is the parent process and the rest are content processes. Do you think it's possible to collect more metadata about the processes? How can we help users know which process to select? I'm also thinking that we could add "debug process" links from about:debugging#tabs. But thinking about Gijs' question in Bug 1420231, who wants to debug the "background thumbnailing process", how can we make it easy to know which process it is. Moving forward, it would be interesting to think about the consistency of our debugging UIs. We have #addons and #workers which open toolbox windows, while #tabs and #processes open new tabs to about:devtools-toolbox. Since we can't go for tabs everywhere (some toolbox need to spawn a new instance of firefox when debugging the current FF instance), maybe about:devtools-toolbox toolboxes should also be opened in new windows.
Flags: needinfo?(poirot.alex)
(In reply to Julian Descottes [:jdescottes][:julian] from comment #1) > - are we getting all the processes that can be interesting debug targets? > Are there other processes used by FF beyond the parent and content processes? I'm not sure. We are reaching all processes that "@mozilla.org/parentprocessmessagemanager;1" nows about: https://searchfox.org/mozilla-central/source/devtools/server/actors/process.js#10,26 > - our processes lack metadata, we only have the id (which is the index of > the process) and assume that id==0 is the parent process and the rest are > content processes. Do you think it's possible to collect more metadata about > the processes? How can we help users know which process to select? I'm also > thinking that we could add "debug process" links from about:debugging#tabs. > But thinking about Gijs' question in Bug 1420231, who wants to debug the > "background thumbnailing process", how can we make it easy to know which > process it is. I think that is related. By default parentprocessmessagemanager components reports 3 processes. I thought, the first one was the parent process, but may be I was mislead by the lack of any information if you look at ppmm.getChildAt(x) returned object, which, by default, implements only ChromeMessageSender. When I worked on this code I tried to extract metadata out of these objects, but did not managed to pull anything. May be the only way would be to evaluate a frame script and send message back to the actor... Or use something else than ppmm to iterate over processes/message managers? Or contribute to ppmm c++ to expose useful data. It starts from here: https://searchfox.org/mozilla-central/source/dom/base/nsFrameMessageManager.cpp#1967 In order to see if you can reach the thumbnail process, you may try to compare message manager from process.js and BackgroundPageThumbs.jsm: https://searchfox.org/mozilla-central/source/toolkit/components/thumbnails/BackgroundPageThumbs.jsm#259 Also, now that I look at this code in process.js and root.js, I'm wondering if the convention where ppmm.getChildAt(0) represents the parent process makes any sense. I think I was mislead and 0 may represent another viable process to debug, different from the parent process. > Moving forward, it would be interesting to think about the consistency of > our debugging UIs. We have #addons and #workers which open toolbox windows, > while #tabs and #processes open new tabs to about:devtools-toolbox. Since we > can't go for tabs everywhere (some toolbox need to spawn a new instance of > firefox when debugging the current FF instance), maybe > about:devtools-toolbox toolboxes should also be opened in new windows. Ideally, and especially when you are debugging remotes where we don't have to open the toolboxes in a distinct process, it would be handy to open toolbox within about:debugging. Like app-manager and WebIde were doing. Having to manage multiple windows is painful UX.
Flags: needinfo?(poirot.alex)
Product: Firefox → DevTools

Main process debugging was implemented

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: