Closed Bug 1440670 Opened 4 years ago Closed 4 years ago

Diagnostic log in Browser Toolbox shows up too when it takes a very long time to connect

Categories

(DevTools :: Framework, defect, P1)

defect

Tracking

(firefox60 fixed)

RESOLVED FIXED
Firefox 60
Tracking Status
firefox60 --- fixed

People

(Reporter: mikedeboer, Assigned: mikedeboer)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

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.
Attachment #8953433 - Flags: review?(jryans) → review+
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
https://hg.mozilla.org/mozilla-central/rev/079080b40f5e
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.