Once bug 878958 and bug 879636 are done, we will be able to debug JS code in FxOS apps and content tabs, using the new protocol drafted here: https://github.com/jimblandy/DebuggerDocs/blob/b2g-subprocesses/protocol At that point, the front-end code for remote debugging that allows one to select which tab to debug needs to be taught how to: - enumerate the main process's child processes, with the "listChildProcesses" request; - attach to the main process's child process actors and get introduced to child process's own root actors; - query those child process root actors for whatever tabs and apps are present in their processes; - present those to the developer as potential debuggees, and let the developer select debuggees; and - handle live changes in tab lists and child process lists, as reported by "tabListChanged" and "childProcessesChanged" notifications. This is, I believe, the final piece needed for FxOS app and content debugging.

I would not have exposed listChildProcesses here. Or at least I would not have made it a key point of making tabs/apps debugging to work on client side. Instead I was thinking about managing the tabs/apps list in the root actor's parent process. This root actor will give few metadata about currently opened tabs/apps and give access to the related child process tab/app actors. So that the client do not have to care about apps/tabs being in child process or not.

(In reply to Alexandre Poirot (:ochameau) from comment #1) > Instead I was thinking about managing the tabs/apps list in the root actor's > parent process. This root actor will give few metadata about currently > opened tabs/apps and give access to the related child process tab/app > actors. So that the client do not have to care about apps/tabs being in > child process or not. Does the parent process have information about apps and tabs that is hard to find in the child process? I think we need a root actor in the child process for other reasons: - profiling in child processes - debugging of in-child chrome code - heap analysis And if that root actor exists, it might as well also serve the purpose of granting access to tab and app JS. But I'm interested in discussing this more.

The parent process knows about all <iframe mozbrowser> and can get a few metadata as it can fetch the appId out of the iframe. But that's pretty much it. With your work, it will also be able to get all child processes and get child actors. But I'm not saying we shouldn't have actors in child! I'm just saying we should return, in parent process listTabs request, the actors names fetched from the child. We shouldn't have to modify anything in the connect page or anything on client side. When client do a listTabs request, he should immediatly get tabs and apps actors, without having to play with listChildProcess and without having to know if a tab or app is remote or not.

Jim, is this still necessary or did the work Alex did render this redundant?

Since we've decided to take the direction Alex suggested for tabs and apps on FxOS, and for tabs when using E10S, we don't need to talk about child processes directly. However, if we want to debug chrome code in child processes, or do profiling, I think we will still want to be able to address the child processes directly. So I think this should stay open, but it's no longer a blocker for FxOS app development.

OK, marking as P3 then since it's not super-urgent.

Alex, is this bug still relevant?

All has been said in comment 5.

Leaving this open for now then :-)

Given that we already have a way to reach the child process through the messageManager and we're also thinking of converting to the Chrome protocol as well, I don't think we would try to change our approach for reaching the child process in our own protocol anymore. If the situation changes, we can always revisit this work later.

I'm fine with closing this. Things have moved on, and I don't think it's worth pursuing the original design.