883249 - Show progress indicator while fetching initial sources

Status: RESOLVED DUPLICATE of bug 927673

(DevTools :: Debugger, defect, P3)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

When you open a debugger window it can take a while before script sources show up. Having some indication that they've being loaded would be useful indicator that debugger actually is aware that there are some scripts on the page and they've being loaded.

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

You can see how that looks in practice, specially confusing part is message saying "page has no sources" for about 20 secs.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

https://vimeo.com/68396306

Comment 3

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

Link is 404ing for me.

There are two cases:

1. When you open the debugger after loading the page and all scripts have been GC'd already, we won't get any sources until you refresh

2. Sources loading slowly. We could use a spinner or something. Random idea: We could also probably speed up filling in a list of sources by forcing "newSource" packets to be fired when we send a "sources" packet. That way, the user gets incremental feedback as individual scripts are loaded, even if the total load time is about the same.

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Ok vimeo failed so here is youtube https://www.youtube.com/watch?v=GTe4PgcR5r4

Comment 5

[Girish Sharma [:Optimizer]]

One solution that I see:

Have the initial text say something like "Checking whether sources exists or not" and when we get the scripts list event from debugger server, we are sure of how many sources are present. At that point, if no sources are present then we can revert back to saying "No script for current page" otherwise we have already showed the scripts.

Comment 6

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

"page has no sources" aside, I'm seeing no source groups in your case. We used to have the same issue with app:// urls, not it seems to be happening again for file://? Sigh...

Comment 7

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

The algorithm seems to be working ok for those particular uris. Runnig this in a scratpchad: http://www.pastebin.mozilla.org/2530858 gets you what you want.

Panos, I remember you figured out what the problem with app:// schemes was. Could it be happening for file:// as well?

Comment 8

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

The problem with app:// URLs was that the protocol handler wasn't getting packaged in Firefox builds, only B2G ones. file:// URLs have been used in desktop since the dawn of time, so I doubt it's the same issue.

Tried to reproduce the slowness with a local clone of interactivate, but it loads pretty fast for me on the latest nightly and the source grouping works as expected, both in a symlinked build and in a packaged one.

In any case the progress indicator suggestion is a valid one and I've been meaning to file this bug for a while. I think that we need a more generic UI though, not debugger-specific, because working on a remote target is always going to be slow no matter what.

The extra newSource packets is an interesting idea, but it needs delicate fine-tuning to make sure it doesn't actually increase latency in the common case.

Comment 9

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

(In reply to Panos Astithas [:past] from comment #8)
> In any case the progress indicator suggestion is a valid one and I've been
> meaning to file this bug for a while. I think that we need a more generic UI
> though, not debugger-specific, because working on a remote target is always
> going to be slow no matter what.

+1

> The extra newSource packets is an interesting idea, but it needs delicate
> fine-tuning to make sure it doesn't actually increase latency in the common
> case.

I suspect that this won't be needed once my patch in bug 757408 lands. The handling of "sources" packets will be much faster.

If we ever revisit this idea, I think it would be nice to do something like what we do with frames where we can load the first n number of frames instead of forcing "newSource" packets. A little harder to do though, because we can't guarantee that the number of sources hasn't changed since our last "sources" request.

Comment 10

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

More of a good second or third bug, than first. Leaving mentorship.

Comment 11

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

fitzgen and I discussed the UI with shorlander and the recommendation was to use a horizontal bar below the tool-specific toolbar (so this metaphor can be used in other tools as well), similar to the one in pdf.js. Stephen suggested a blue-ish color, and I'd vote for a drop-like effect just like chrome for android :-)

Comment 12

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

(In reply to Panos Astithas [:past] from comment #11)
> fitzgen and I discussed the UI with shorlander and the recommendation was to
> use a horizontal bar below the tool-specific toolbar (so this metaphor can
> be used in other tools as well), similar to the one in pdf.js. Stephen
> suggested a blue-ish color, and I'd vote for a drop-like effect just like
> chrome for android :-)

This was for loading source text, though. Do we want to do the same for loading the list of sources (this bug)?

Filed bug 912586 for the source contents.

Comment 13

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

My intention was always to use a single progress indicator across all of our tools, for any kind of interaction, barring any unforeseen difficulties of course. I remember there was agreement on that point (or at least I don't remember any disagreement), isn't that accurate?

Comment 14

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

I'd say that having a global progress indicator would make a lot of sense, assuming the UX/UI part of things is taken care of (where to put it? how it would look like? will it look the same for all tools? is it always a progress indicator or can it also be an activity indicator?).

Many of our tools deal with sources and the source editor to some extent (Debugger, Style Editor, Network Monitor, maybe soon the GLSL Editor as well), where a progress indicator for fetching + displaying the source text would make sense. The Profiler could also defer to the toolbox progress bar instead of baking things into its own when creating the view.

Sounds like there's a lot of stuff to figure out here.

Comment 15

[Girish Sharma [:Optimizer]]

I would go along with what Panos suggested in comment 11 and to make it global, we can just move it above the tool specific toolbar, that is, below the toolbox tabs toolbar.

Comment 16

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

(In reply to Panos Astithas [:past] from comment #13)
> My intention was always to use a single progress indicator across all of our
> tools, for any kind of interaction, barring any unforeseen difficulties of
> course. I remember there was agreement on that point (or at least I don't
> remember any disagreement), isn't that accurate?

I guess I was assuming that the loading of the list of sources would have a spinner but the loading of source text would have a progress bar. I think this is an unfounded assumption.

Comment 17

[Hubert B Manilla]

I guess Bug 927673 sorts this bug out?

Comment 18

[Hubert B Manilla]

(In reply to Hubert B Manilla from comment #17)
> I guess Bug 927673 sorts this bug out? ...or part of it?

Comment 19

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

(In reply to Hubert B Manilla from comment #17)
> I guess Bug 927673 sorts this bug out?

Yeah I think we can dupe this bug to that one.