934714 - Work - Don't show progress bar on Start page

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: Firefox Start, defect)

Description

[Sam Foster [:sfoster] (he/him)]

Yuan suggest we not show the loading progress bar on the Start page - it only adds distraction.

Comment 1

[Sam Foster [:sfoster] (he/him)]

Attachment: Dont track loadingState for about:start, collapse progressbar when not loading

There's lots of ways to achieve the goal of this bug. I made the progressbar container's visibility tied to the loading attribute. Then, for about:start we don't update the loading value. That seems to get closest to what we mean. Open to other ideas though

Comment 2

[Rodrigo Silveira [:rsilveira] [:rodms]]

Comment on attachment 828773 [details] [diff] [review]
Dont track loadingState for about:start, collapse progressbar when not loading

Review of attachment 828773 [details] [diff] [review]:
-----------------------------------------------------------------

This patch is causing the progress bar to abruptly disappear after loading, instead of the nice fade we have. One option is to use the startpage attribute to set the visibility collapse on #progress-container.

Comment 3

[Sam Foster [:sfoster] (he/him)]

Attachment: observe windowState to toggle progressbar, call browserUI.update to reset windowState in time

Take 2. Following IRC discussion, this patch has the progressbar container observing the windowState to turn off when startpage is truthy. We can't just default startpage to true because we have an artivation url or being restoring a session. But we do update the windowState when newTab is called, via the selectedTab setter. Except that currently skips this step for the first tab case. So I modified that logic so BrowserUI.update is always called there, which will set startpage=true, which will hide our progressbar. 

Its not perfect, you see a glimpse of it as you startup. But I think it might be good enough?

Comment 4

[Rodrigo Silveira [:rsilveira] [:rodms]]

Comment on attachment 829019 [details] [diff] [review]
observe windowState to toggle progressbar, call browserUI.update to reset windowState in time

Review of attachment 829019 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good and works.

Comment 5

[Sam Foster [:sfoster] (he/him)]

On fx-team: https://hg.mozilla.org/integration/fx-team/rev/4e420e56d7f4

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4e420e56d7f4

Comment 7

[Alexandre Folle de Menezes]

Shouldn't this be done for all the other about:xxx pages too?

Comment 8

[Sam Foster [:sfoster] (he/him)]

Yuan, what do you think? I dont think it hurts any on the other about: pages, but we could easily do it.

Comment 9

[Yuan Wang(:Yuan) – Mobile Firefox Design Lead]

I think it makes sense to apply this to other about: pages too. One overall design goal on those in-content pages(from desktop to mobile) is to make it feel less like a webpage, more like one part of chrome. 

If the in-content pages can be displayed without any perceived waiting time, we should go ahead and disable showing progress bar.

Comment 10

[Sam Foster [:sfoster] (he/him)]

Follow-up bug as bug 937234. This bug was always about about:start specifically and blocks the Start Page transitions story, which is now complete.