1092821 - Opening Inspector in Browser Toolbox is slow

Status: NEW

(DevTools :: Framework, defect)

Description

[mcdavis941 (sporadically reading bugmail)]

This bug is about the time it takes from the point when you decide you want to inspect chrome to the point when you're up and inspecting.

To inspect the main browser window:

- with DOM Inspector, about 2 to 3 seconds
- with Browser Toolbox, about 22 to 23 seconds

Part of the time for Browser Toolbox is saying yes to the remote connection prompt.  It would save a couple seconds if that prompt appeared on top, but right now it appears behind the toolbox window.  

I'd guess another big part of the delay is all that disk I/O on my non-SSD system.  

Developer Tools are really great and they've helped me solve several problems that would have been hard without them, but that's a big time difference.

Comment 1

[Brian Grinstead [:bgrins]]

FWIW, the prompt can be disabled via the devtools.debugger.prompt-connection pref (which I've added to this doc: https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox).

Bug 1031404 won't completely solve the rest of this, but I think that once it is resolved this would speed things up considerably since the debugger panel wouldn't have to initialize immediately if you had been using the Inspector last.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Bug 1013379 will also remove the need to set a pref in order to avoid the prompt.

Comment 3

[Sebastian Zartner [:sebo]]

As outlined in bug 1378964, the DOM Inspector can also be very slow.

Sebastian

Comment 4

[Matthew N. [:MattN]]

(In reply to Sebastian Zartner [:sebo] from comment #3)
> As outlined in bug 1378964, the DOM Inspector can also be very slow.

"DOM Inspector" in this bug is talking about the separate extension by that name which was used for debugging the browser chrome.

Comment 5

[Sebastian Zartner [:sebo]]

(In reply to Matthew N. [:MattN] (huge backlog; PM if requests are blocking you) from comment #4)
> (In reply to Sebastian Zartner [:sebo] from comment #3)
> > As outlined in bug 1378964, the DOM Inspector can also be very slow.
> 
> "DOM Inspector" in this bug is talking about the separate extension by that
> name which was used for debugging the browser chrome.

Ah, I totally missed that. Thanks for the clarification!

Sebastian

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

Here's a profile of the Browser Toolbox initialization: https://share.firefox.dev/3stC784 (recorded via MOZ_BROWSER_TOOLBOX_PROFILER_STARTUP=1 ./mach run --jsdebugger)

DevTools code starts to kick in at ~2s, but we have to wait ~7s to see anything rendered onto the window; finally at ~11s the (3 pane) inspector is fully rendered.

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

We looked into this as part of numerous similar bugs.

The problem is that most tool panels are not populated until page / DOM load so if the page takes 20 seconds to load then the DevTools panels will be blank for 20 seconds and will then render.

There is also the issue that the DevTools panels do not become populated if the load event is not fired (this happens when document.write() is used).

Waiting makes sense because then we only need to iterate through the DOM nodes once to get style information etc.

Maybe changing the UX to make it clearer what is happening would help? (skeleton pages, messages "Waiting for DOM load", progress bars etc). This is the most pragmatic solution... we planned on implementing this at some point but there were never enough developers spare to do it.

We could also render the tools as pages are loaded but that could slow down content page loading.

Just my 2 pence ;)

Comment 8

[Julian Descottes [:jdescottes]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #6)

Here's a profile of the Browser Toolbox initialization: https://share.firefox.dev/3stC784 (recorded via MOZ_BROWSER_TOOLBOX_PROFILER_STARTUP=1 ./mach run --jsdebugger)

DevTools code starts to kick in at ~2s, but we have to wait ~7s to see anything rendered onto the window; finally at ~11s the (3 pane) inspector is fully rendered.

And at 7s it seems we haven't started executing any JS for the inspector yet (at least none which shows up in the profile). I will add markers to get a better idea of the flow here.

But if we can confirm that most of the time spent here is actually simply spent to start the toolbox, we can probably close this bug since we have other bugs to speed up the Browser Toolbox. From a tool perspective, the inspector is normally quite conservative about the requests it makes to display its UI. It will only request information for nodes which are displayed in the markup view. And since the markup view tree is never fully expanded at initialization time, it should actually have comparable performance between the regular web toolbox and the browser toolbox.

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Doug, you can look Comment 6 for a profile of Browser Toolbox opening

To record your own:

1. MOZ_BROWSER_TOOLBOX_PROFILER_STARTUP=1 ./mach run --jsdebugger
2. In the Browser Toolbox that opened, hit the Browser Toolbox keyboard shortcut (Cmd+Alt+Shift+i)
3. It will open a new Browser Toolbox, targeting the first one. You can then select the Performance panel and hit the "Capture" button there to get the profile