The tab consoleActor is entirely silent on b2g because page errors, console api calls and network requests cannot be associated to the top level chrome window of b2g. Findings: 1. outerWindowID is almost always 0 for nsIScriptError objects. When it is provided, the ID doesn't match the top chrome window of b2g (the window that loads shell.xul). 2. nsIScriptError.category is generally fine. 3. console API messages seem to have outer window IDs, but they don't match the top level chrome window (shell.xul). 4. no network request can be logged because the nsILoadContext of the nsIHttpChannel does not have the |associatedWindow| property. I get NS_ERROR_UNEXPECTED whenever I try to read that property. For the few cases when I get window IDs, their URLs are of the form: http://system.gaiamobile.org:8080/ http://keyboard.gaiamobile.org:8080/ http://browser.gaiamobile.org:8080/ ... etc This seems to suggest we can have some system-known windows and per app windows? Or am I wrong? This bug report is about: figuring out if we want to make the tab consoleActor work (and how?), or just remove it. Here we should also get a perspective on a very related topic: do we want a consoleActor per app? How do we do that in b2g? I learned from Rob that there's a plan to have per-app processes. Looking forward for thoughts and suggestions. Thanks!
Adding a patch I used for logging so I can learn more about what works and what doesn't. (might be helpful for others who want to investigate)
Many apps are launched in separate processes already in B2G, but I don't think this is supported in desktop builds (maybe in the emulator?). We will add remote protocol support for that in bug 797627. CCing Chris Jones for insight into the weirdness of window IDs in B2G.
Not really following along here, but the emulator and desktop b2g builds load "apps" in separate processes as well. AFAIK window IDs don't transfer across processes out of the box, but can be made to do so by concatenating them while traversing the process tree.
> Many apps are launched in separate processes already in B2G, but I don't think this is supported > in desktop builds Multi-process is supported on desktop B2G on Mac and Linux. Thank you for fixing this bug, by the way. It will make it /much/ easier to debug JS.
Content processes should work quite well with basic or d3d9 layers on windows, as well. However, d3d10 layers will not work well on win7. (Long story.)
This was fixed by the work to put the debugger server into the content process for the app being debugged.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.