902152 - Investigate not selecting and displaying any source by default on debugger startup

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P3)

Description

[Victor Porof [:vporof][:vp]]

Chrome started doing this in Canary.

Advantages:
1. Faster startup (especially when it comes to large sources, see also bug 898470)
2. No way to actually know the desired initial source, so not loading anything seems pertinent
3. Lets people know about sources filtering ("hit cmd+P to open a file")
4. Subsequent reloads would select the previous file anyway
5. After bug 883238, point 4 would be true across sessions too

Disadvantages:
1. Annoying when only one source is available (in this case, maybe we should just select it by default)
2. Could be unexpected

Thoughts?

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

+1 Setting text is a HUGE slow down at startup. Like ~30% of time IIRC.

+1 to showing the one source if there is only one.

+1 to fetching source texts in the background but not displaying them so they are ready to go when the user does select a source: bug 980532.

We discussed this a little at the last team meetup and it seemed like some people didn't want this? Why not?

Comment 2

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

Chrome still loads the source by default for me. My argument against it is that people expect the debugger to display a source, an empty editor pane would break POLA. Furthermore, I posit that we are already doing a decent job of figuring out the most important source to show in many cases (let's do even better!), which improves perceived startup speed. With an empty editor one always has to click/scroll before he can inspect or interact with the source.

Also note that we are currently using the debugger and the style editor from the console as a modern view-source. In those use cases starting with an empty editor is clearly the wrong thing to do.

There is often a tradeoff between throughput and latency. The user opens the debugger in all of those cases with a specific action in mind. I'm arguing that what is most important here is how fast we can get the entire job done (glance at the file, set a breakpoint, whatever), not just how fast the debugger panel will open.

Comment 3

[Eddy Bruel [:ejpbruel]]

I'm with Panos on this one. I would prefer to look at options to make this faster that don't affect the user experience.

Comment 4

[Asher]

Not loading the JavaScript code in the debugger seems to happen often on startup (30%).

Comment 5

[Jason Laster [:jlast]]

Closing because in the new UI with tabs it is easy not to have any tabs selected which should speed it up on open.