978874 - Loading bar animation makes page load seem to take longer than it actually is

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

Side effect of Bug 970719.

<AaronMT> aside I can't believe we show a slow progress bar for simple pages
<AaronMT> there's literally a slow loading progress bar for data:text/html,<textarea>this is a testcase</textarea>

<bnicholson> one option would be just flashing the progress bar at 100% after a stop without doing any additional animation

<AaronMT> With the same URL in Chrome, there's no progress it's so fast you just see the entire progress bar flash and disappear immediately

Comment 1

[Aaron Train [:aaronmt]]

Compare progress bar in Firefox vs Chrome by loading 'data:text/html,'

Comment 2

[Brian Nicholson (:bnicholson)]

I'd say this is more "by design" than a "side effect" of bug 970719. The progress bar quickly animates to the end after the page stops loading, and that's exactly what bug 970719 was supposed to do.

If we want to keep the post-stop animation, we could make the animation faster. If not, we could instantly jump the progress bar to 100% before making it disappear.

Comment 3

[Aaron Train [:aaronmt]]

My $0.02, if we know a document is done, the progress bar should jump to the end.

Comment 4

[Brian Nicholson (:bnicholson)]

Just some numbers: bug 970719 adds an additional 10 steps of animation for post-stop. Each of these steps takes 10ms, so the perceived additional page load time is 100ms.

Comment 5

[Ian Barlow (:ibarlow)]

See the "shooting across the screen" bit in the mockups here? https://bugzilla.mozilla.org/show_bug.cgi?id=867633#c1

That is the thing I want here.

Comment 6

[Brian Nicholson (:bnicholson)]

(In reply to Ian Barlow (:ibarlow) from comment #5)
> See the "shooting across the screen" bit in the mockups here?
> https://bugzilla.mozilla.org/show_bug.cgi?id=867633#c1
> 
> That is the thing I want here.

Sorry for not being descriptive enough in the last NEEDINFO -- I'll try to provide a little more context here.

There are several states we receive from Gecko to let us know how far along in the page load we are. The final event we receive, STOP, tells us that the page has finished loading, so we move the progress bar to the end and hide it.

No matter how we end up animating the progress during page load, we'll end up shooting the progress bar to the end after we receive the STOP event (both currently and in the movie you linked to). In an ideal world, we could predect the future and know exactly when the STOP will happen, so we would time it perfectly to make the animation finish right as the page finishes loading. That's obviously impossible, though, so the finishing animation has to happen *after* the page has loaded. This means the progress bar must be on the screen longer than the spinning throbber was since the spinning throbber never had to worry about this finishing animation.

For pages that load quickly, this extra animation will be noticeable since it adds 100ms to the throbber's visibility time (which would otherwise be close to zero). If we want any post-stop animation (which we have now, and which we'll need to for anything similar to your mockups), this extra perceived load time is unavoidable. So given that your mockups still include this animation, am I correct that this should be marked WONTFIX?

Comment 7

[Ian Barlow (:ibarlow)]

Yeah. We could explore making the "done" animation faster though, if we wanted to.