With the Debugger pane selected to open on startup, it may take as much as 12 seconds to finish a `connect()`, but the timeout to show the connection status only allows for 5 seconds, which means that it gets shown erroneously. This probably not the intended behavior, especially since there are no means to dismiss the log.

Is this in a debug build? Does your initial Firefox startup take approximately the same amount of time? That's a really long time to have to wait for the Browser Toolbox to open :(. Seems like we could at least: - dismiss the diagnostic log once a connection succeeds - bump up the time limit before initially showing it

(In reply to Brian Grinstead [:bgrins] from comment #1) > Is this in a debug build? Does your initial Firefox startup take > approximately the same amount of time? That's a really long time to have to > wait for the Browser Toolbox to open :(. > > Seems like we could at least: > > - dismiss the diagnostic log once a connection succeeds > - bump up the time limit before initially showing it Yeah, that's what I did. I am using a debug build and Standard8 was too, which might have something to do with it. Regardless, I implemented your suggestions.

Another thing we could do as a follow-up is implement some kind of loading UI with a spinner and a toggleable view of the diagnostic log, so it feels less broken during super long startups.

Comment on attachment 8953433 [details] Bug 1440670 - Make the timeout before showing the connection status in the Browser Toolbox longer and hide it whenever the connection is established. https://reviewboard.mozilla.org/r/222690/#review228642 Thanks and sorry for the trouble! This seems like a good improvement, and we can keep thinking through a better loading UI like :bgrins mentions as a follow up.

I wonder how much of the slowness is the debug build in the browser toolbox process as far as loading the toolbox vs the debug build in the debuggee server for accepting the connection, sending sources, etc. Because if it's primarily the former we could consider opening a release firefox binary for the BT frontend. It could open a can of worms for backwards compat (old client + new server) but I suspect it would be a lot faster. If you wanted to try that out locally to see if it would help, you could do: `./mach run --start-debugger-server 6080` Then in a second window run something like this (adjusting the binary path and temp folder depending on your platform): `MOZ_BROWSER_TOOLBOX_PORT=6080 /Applications/FirefoxNightly.app/Contents/MacOS/firefox --profile /tmp/bt -chrome chrome://devtools/content/framework/toolbox-process-window.xul --purgecaches --jsconsole`

Pushed by mdeboer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/079080b40f5e Make the timeout before showing the connection status in the Browser Toolbox longer and hide it whenever the connection is established. r=jryans