This happens because, in toolbox.js, domReady in toolbox.open() is called too early. Probably related to bug 936892.

I had this happen for a bit and then it went away. I wonder if the XUL cache or its friends are involved.

(In reply to :Gijs Kruitbosch from comment #1) > I had this happen for a bit and then it went away. I wonder if the XUL cache > or its friends are involved. This is very likely.

I get the same problem, but I see the following error in the console of the Browser Toolbox process: [Exception... "Component returned failure code: 0x804b000d (NS_ERROR_CONNECTION_REFUSED) [nsIInputStream.available]" nsresult: "0x804b000d (NS_ERROR_CONNECTION_REFUSED)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/security/socket.js :: onInputStreamReady :: line 300" data: no] This is after starting the main process with ./mach run --jsdebugger then closing the Browser Toolbox, and opening another process with basically the same command that runs from ToolboxProcess.jsm [0]: ./mach run --no-remote --foreground --profile /tmp/chrome-debugging -chrome chrome://browser/content/devtools/framework/toolbox-process-window.xul --purgecaches --jsconsole [0]: https://dxr.mozilla.org/mozilla-central/source/browser/devtools/framework/ToolboxProcess.jsm#208

With this patch, it at least prints out the error message in the toolbox instead of showing a blank page. Here is a way I can reliably trigger an error connecting: 1) ./mach run --jsdebugger 2) Close the browser toolbox 3) ./mach run --profile /tmp/foobar -chrome chrome://browser/content/devtools/framework/toolbox-process-window.xul --purgeches --jsconsole 4) You should see the error message from Comment 3 in the opened window

Comment on attachment 8578930 [details] [diff] [review] browser-toolbox-error-message.patch I am okay with adding this error display, but I think we should move this to a separate bug, because it does not solve the issue originally reported, and your case is different anyway. Maybe this bug can depend on a bug with your error patch, to aid debugging the original issue? I think it makes sense, but let me know if it seems like too much bookkeeping work... This bug is about using the normal Browser Toolbox from the menu item, but getting the blank window. Your steps change the assumptions of the Browser Toolbox: it stops the server when the toolbox (that was launched via its menu item) is closed. So, the second toolbox you start for the terminal has no server to connect to. To run Browser Toolbox manually like you're doing here, I will typically start the server manually with "listen 6080" in GCLI. That way the server is manually managed, and won't be terminated when the Browser Toolbox closes. I just tried this now, and it does get around the nsIInputStream exception your reported. However, it gives a different error, which does not appear in your error display on shut down: Handler function threw an exception: [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js :: TabActor.prototype.window :: line 676" data: no] Stack: TabActor.prototype.window@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:676:0 TabActor.prototype._windowReady@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1389:8 TabActor.prototype._changeTopLevelDocument/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/actors/webbrowser.js:1354:6 makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:82:13 Line: 676, column: 0

(In reply to J. Ryan Stinnett [:jryans] from comment #5) > Comment on attachment 8578930 [details] [diff] [review] > browser-toolbox-error-message.patch > > I am okay with adding this error display, but I think we should move this to > a separate bug, because it does not solve the issue originally reported, and > your case is different anyway. Maybe this bug can depend on a bug with your > error patch, to aid debugging the original issue? I think it makes sense, > but let me know if it seems like too much bookkeeping work... > Filed bug 1144392 for this. > This bug is about using the normal Browser Toolbox from the menu item, but > getting the blank window. Your steps change the assumptions of the Browser > Toolbox: it stops the server when the toolbox (that was launched via its > menu item) is closed. So, the second toolbox you start for the terminal has > no server to connect to. I actually had the same problem when just closing and reopening the browser toolbox with the menu but I knew it didn't reproduce for other people. But will need to investigate this problem further when manually listening from the first process.

Are we getting any update on this asap? I am really not able to debug any addon due to same error comes up while clicking debug button on addon. I have also found that now I don't see any window prompting me to accept connection to ip and port address.

(In reply to akanshgulati2009 from comment #7) > Are we getting any update on this asap? I am really not able to debug any > addon due to same error comes up while clicking debug button on addon. I > have also found that now I don't see any window prompting me to accept > connection to ip and port address. Since you aren't seeing the prompt, this could be the same issue as originally reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1438962#c0. We landed some changes that print out diagnostics to help debug this issue, so if you can test with the most recent Nightly build and report back the log you see that would be helpful (it should show up in the addon toolbox window after ~20s if the toolbox fails to open).

@Brian G(In reply to Brian Grinstead [:bgrins] from comment #8) > (In reply to akanshgulati2009 from comment #7) > > Are we getting any update on this asap? I am really not able to debug any > > addon due to same error comes up while clicking debug button on addon. I > > have also found that now I don't see any window prompting me to accept > > connection to ip and port address. > > Since you aren't seeing the prompt, this could be the same issue as > originally reported in > https://bugzilla.mozilla.org/show_bug.cgi?id=1438962#c0. We landed some > changes that print out diagnostics to help debug this issue, so if you can > test with the most recent Nightly build and report back the log you see that > would be helpful (it should show up in the addon toolbox window after ~20s > if the toolbox fails to open). Thanks man. I installed Nightly in a freshly created new user on Mac OS and debugging of addon started working with and without prompt window of connection.