597592 - Progress line indicator should match OS colour scheme

Status: RESOLVED WONTFIX

(Firefox :: Theme, defect)

Description

[[not reading bugmail]]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre
Build Identifier: 

This got implemented as blue in bug 578028 and should be fixed to match the mockups.

Reproducible: Always

Actual Results:  
Progress Line is Blue

Expected Results:  
Progress Line should stick with Green, Green is already a standard color progress indicator.

Comment 1

[[not reading bugmail]]

mockup for background tab: attachment 425750 [details]

mockup for foreground tab: attachment 470022 [details]

Comment 2

[Aaron Train [:aaronmt]]

Agreed should be green imo

Comment 3

[Dave Garrett]

Blue was used for status bar progress. I like blue better, personally. Varying the color with themes might be wanted by some, but would probably lead to inconsistency and possible user confusion.

Compromise idea: gradient, blue blending into green. Not just a pretty idea, but it would be pseudo-informative. Blue would be starting and green is "going" so getting done. Might be an idea for another "looks faster-ish" quirk.

Comment 4

[u88484]

I also agree that the progress line's color should be green as it was in the mockups.  I can barely see the progress line with tabs on top do to the blue mixing in with the toolbar background color on windows 7.  It just blends in way too much.

CC'ing the UI/UX experts here.

Comment 5

[Dominic]

(In reply to comment #3)
> Compromise idea: gradient, blue blending into green. Not just a pretty idea,
> it would be pseudo-informative. Blue would be starting and green is "going"
> so getting done. Might be an idea for another "looks faster-ish" quirk.

You might be onto something.
It wouldn't change color with the percentage, per se, but the site-finding process information. e.g. has the domain been found, is it loading, is it waiting, etc.

Comment 6

[Matthew Turnbull [Bluefang]]

Attachment: green progress lines with modified color transition

This is what I've been using. I find it works pretty well for me.
This also makes the color transition a bit easier to discern.


.tab-progress > .progress-bar,
#urlbar-progress > .progress-bar
{
	background-color: rgb(25, 255, 25) !important;
	background-image: none !important;
}

#urlbar-progress > .progress-remainder
{
	background-image: -moz-linear-gradient(left,
				rgba(25, 255, 25, 1),
				rgba(255, 255, 255, 0) 60px) !important;
	background-color: threedlightshadow !important;
}

.tab-progress > .progress-remainder
{
	background-image: -moz-linear-gradient(left,
				rgba(25, 255, 25, 1),
				rgba(255, 255, 255, 0) 30px) !important;
	background-color: threedlightshadow !important;
}

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

I believe we just checked in the OS X style to get this landed.  Either way, the plan is for these colors to be platform native, so this bug can't be platform:all

Comment 8

[u88484]

Changing the OS back to Windows 7 then as this bug was originally filed for windows 7.  Alex, do you have a specific color so someone can create a patch with those numbers?

Comment 9

[[not reading bugmail]]

Updating summary to match.

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

>do you have a specific color so someone can create a patch
>with those numbers?

We'll likely want to use a gradient similar to the native progress bar, I'll default to Stephen's call.

Comment 11

[Stephen Horlander [:shorlander]]

Attachment: Progress Line Visual Style Update v01

Updates the visual style of the progress lines:

- Green progress on Windows
- Blue URL progress on OS X with slightly desaturated colors for the tabs
- More contrast between progress and remainder on all

Trying to respect the Linux system theme colors is going to be hit or miss depending on the theme as seen in the screenshot.

Comment 12

[Stephen Horlander [:shorlander]]

Attachment: Screenshot of Patch v01

Comment 13

[Gabriela [:gaby2300]]

Yes! Green looks much nicer and it's much more visible.

Comment 14

[Matthew Turnbull [Bluefang]]

Unfortunately, the Windows progress bar is the only one that doesn't blend in with the rest of the UI. Keeping with platform convention is good until feature usability is marginalized.

Well, regardless of what happens, at leas I know I can change it later.

Comment 15

[Dave Garrett]

(In reply to comment #11)
> Trying to respect the Linux system theme colors is going to be hit or miss
> depending on the theme as seen in the screenshot.

It looks like you're going to need better interpretation of what goes with what. Grey is not a good progress bar color, well, ever. I thought we were considering to use that color when the connection was broken.

The color should only be within a green-ish or blue-ish range or it won't have the desired look of a progress bar. (i.e. anywhere such as light/dark greens/blues or even various purples would work)

Comment 16

[Dão Gottwald [:dao]]

Stephen, it looks like you're also trying to fix the vertical alignment of the progress line. The misalignment is a more general problem which I'm attempting to fix in bug 597592, so we shouldn't workaround it here.

Comment 17

[Dão Gottwald [:dao]]

Another minor note on the patch: -moz-border-radius is an alias, Gecko supports the standard border-radius notation as of recently.

Comment 18

[Stephen Horlander [:shorlander]]

Attachment: Progress Line Visual Style Update v02

(In reply to comment #16)
> Stephen, it looks like you're also trying to fix the vertical alignment of the
> progress line. The misalignment is a more general problem which I'm attempting
> to fix in bug 597592, so we shouldn't workaround it here.

Great! I removed the [pinned] rules.

(In reply to comment #17)
> Another minor note on the patch: -moz-border-radius is an alias, Gecko supports
> the standard border-radius notation as of recently.

I forgot about that :) Updated to standard border-radius rules.

Thanks!

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

If this gets review it's got my permission to go in for beta7.

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #18)
> (In reply to comment #16)
> > Stephen, it looks like you're also trying to fix the vertical alignment of the
> > progress line. The misalignment is a more general problem which I'm attempting
> > to fix in bug 597592, so we shouldn't workaround it here.
> 
> Great! I removed the [pinned] rules.

It's not just those rules, pretty much all of your margin changes shouldn't be needed, I think.

Also -moz-box-shadow is box-shadow now.

Comment 21

[Stephen Horlander [:shorlander]]

(In reply to comment #20)
> (In reply to comment #18)
> > (In reply to comment #16)
> > > Stephen, it looks like you're also trying to fix the vertical alignment of the
> > > progress line. The misalignment is a more general problem which I'm attempting
> > > to fix in bug 597592, so we shouldn't workaround it here.
> > 
> > Great! I removed the [pinned] rules.
> 
> It's not just those rules, pretty much all of your margin changes shouldn't be
> needed, I think.

Ok. I should have just built on your patch to see what happens :) 

> Also -moz-box-shadow is box-shadow now.

I have to remember all this new stuff. Thanks!

Comment 22

[Stephen Horlander [:shorlander]]

Attachment: Progress Line Visual Style Update v03

- Updated the -moz-box-shadow rules to box-shadow
- Removed the margin adjustments on .tab-progress-container

This works with the patch from bug 597353.

Comment 23

[Alex Limi (:limi) — Firefox UX Team]

I would like to nominate this for inclusion in beta7, so we get feedback from a real release on this, since it's closer to how it was intended to be.

If this implementation ends up being too subtle for people still, then we'll make it more visible similar to some of the suggestions (but not the title) in bug 597971. 

Having this change in a release vehicle should give us the feedback we need, and it's an extremely low-risk patch, since it just changes CSS/colors.

Comment 24

[Dão Gottwald [:dao]]

Comment on attachment 478497 [details] [diff] [review]
Progress Line Visual Style Update v03

Not sure what the remaining margin changes are about. This doesn't seem to apply after bug 597353...

Can you use -moz-transform: scaleX(-1) for the rtl styling?

Comment 25

[Dietrich Ayala (:dietrich)]

Marking blocking. The amount of time I've spent squinting at the progress line so far is tangible, and should not be.

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

If the patch gets reviewed in time, renominate and we'll move it to beta7+. Not before then, though.

Comment 27

[Stephen Horlander [:shorlander]]

(In reply to comment #24)
> Comment on attachment 478497 [details] [diff] [review]
> Progress Line Visual Style Update v03
> 
> Not sure what the remaining margin changes are about. This doesn't seem to
> apply after bug 597353...

Even with the patch from bug 597353 applied they don't line up right with the top of the tabs on Mac and Linux but they do on Windows for a reason I can't seem to figure out.

The initial negative margins on #urlbar-progress are for overlapping the bottom border by 1px and to prevent it from increasing the height of the urlbar.

> Can you use -moz-transform: scaleX(-1) for the rtl styling?

I will give that a shot.

Comment 28

[Stephen Horlander [:shorlander]]

Attachment: Progress Line Visual Style Update v04

Updated to tip and use scaleX(-1) for RTL.

Comment 30

[Peter Henkel [:Terepin]]

The PL color on Ubuntu is wrong, orange should be used.

Comment 31

[Mike Beltzner [:beltzner, not reading bugmail]]

The UX team doesn't believe we can get the feedback needed on the new progress bars without this patch; Dao, can we expedite review?

Comment 32

[Dão Gottwald [:dao]]

Comment on attachment 480213 [details] [diff] [review]
Progress Line Visual Style Update v04

> .tab-progress > .progress-bar,
> #urlbar-progress > .progress-bar {
>   -moz-appearance: none;
>   min-width: 3px;
>-  border-top: 1px solid rgba(100,100,100,.1);
>-  border-bottom: 1px solid rgba(0,0,0,.2);
>+  border-top: 1px solid rgba(0,0,0,.2);
>+  border-bottom: 1px solid rgba(0,0,0,.3);
>   background-color: Highlight;
>-  background-image: -moz-linear-gradient(left, rgba(255,255,255,.1) 50%,
>-                                               rgba(255,255,255,.4) 90%,
>-                                               rgba(255,255,255,.8));
>-}
>-
>-.tab-progress > .progress-bar:-moz-locale-dir(rtl),
>-#urlbar-progress > .progress-bar:-moz-locale-dir(rtl) {
>-  background-image: -moz-linear-gradient(right, rgba(255,255,255,.1) 50%,
>-                                                rgba(255,255,255,.4) 90%,
>-                                                rgba(255,255,255,.8));
>+  background-image: -moz-linear-gradient(right, rgba(255,255,255,1),  rgba(255,255,255,.75) 1px, rgba(255,255,255,.1) 30px, rgba(255,255,255,.1));

use 'white' instead of rgba(255,255,255,1)

>+  border-bottom-left-radius: 3px;

Why does the urlbar progress line not have any other radii?

>+.tab-progress > .progress-bar:-moz-locale-dir(rtl),
>+.tab-progress > .progress-bar:-moz-window-inactive:-moz-locale-dir(rtl),
>+.tab-progress > .progress-remainder:-moz-locale-dir(rtl),
>+.tab-progress > .progress-remainder:-moz-window-inactive:-moz-locale-dir(rtl),
>+#urlbar-progress > .progress-bar:-moz-locale-dir(rtl),
>+#urlbar-progress > .progress-bar:-moz-window-inactive:-moz-locale-dir(rtl),
>+#urlbar-progress > .progress-remainder:-moz-locale-dir(rtl),
>+#urlbar-progress > .progress-remainder:-moz-window-inactive:-moz-locale-dir(rtl) {
>+  -moz-transform: scaleX(-1);
> }

:-moz-window-inactive is readundant.

The pinstripe part still doesn't apply after bug 597353...
patching file browser/themes/pinstripe/browser/browser.css
Hunk #1 FAILED at 922

Comment 33

[Gabriela [:gaby2300]]

Does any of this mean we'll be having the green progress lines like the ones in the mockup?

Comment 34

[Josh Tumath]

(In reply to comment #33)
> Does any of this mean we'll be having the green progress lines like the ones in
> the mockup?

That is correct.

Comment 35

[Stephen Horlander [:shorlander]]

(In reply to comment #32)
> Why does the urlbar progress line not have any other radii?

This is to match the bottom left curve of the urlbar in the default toolbar config. It should actually be specific to the whether or not it is in a combined state. Testing this exposed some other strangeness that needs to be fixed as well.

> The pinstripe part still doesn't apply after bug 597353...
> patching file browser/themes/pinstripe/browser/browser.css
> Hunk #1 FAILED at 922

Odd… Since 597353 landed updating to tip should fix it :)

Comment 36

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #11)
> Trying to respect the Linux system theme colors is going to be hit or miss
> depending on the theme as seen in the screenshot.

Indeed. Currently when using the default theme on Fedora 13 the
progress line is barely noticeable.
If the progress line would be also in the (front-most) tab,
it might not be so unnoticeable. Though, still, better color is needed.

Comment 37

[Stephen Horlander [:shorlander]]

Attachment: Progress Line Visual Style Update v05

Addressed comment 32 and fixed up the border-radius and weirdness caused by not having a combined urlbar+stop/go/reload.

Comment 38

[Gabriela [:gaby2300]]

(In reply to comment #34)
> (In reply to comment #33)
> > Does any of this mean we'll be having the green progress lines like the ones in
> > the mockup?
> 
> That is correct.

Good! About when do you think this will be landed on trunk?

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

Please note that we have now created a branch for beta 7 work. In addition to landing your fix on mozilla-central default, please also land it on mozilla-central GECKO20b7pre_20101006_RELBRANCH

(note: when landing on mozilla-central default, you will be given priority in the landing queue at https://wiki.mozilla.org/LandingQueue )

Comment 40

[Stephen Horlander [:shorlander]]

Comment on attachment 481345 [details] [diff] [review]
Progress Line Visual Style Update v05

Cancelling review for now since bug 602126 is probably going to require drastic changes to this patch.

Comment 41

[:Margaret Leibovic]

(In reply to comment #40)
> Comment on attachment 481345 [details] [diff] [review]
> Progress Line Visual Style Update v05
> 
> Cancelling review for now since bug 602126 is probably going to require drastic
> changes to this patch.

I don't think bug 602126 will require you to change this patch, since it seems like bug 602126 just involves the connecting state. Even if replacing the gradient with a PNG in that bug doesn't work, we could just replace the .progress-remainder background with an APNG when it's in the connecting state, then switch back to the original background once the progress meter starts moving.

Comment 42

[Stephen Horlander [:shorlander]]

Comment on attachment 481345 [details] [diff] [review]
Progress Line Visual Style Update v05

(In reply to comment #41)
> (In reply to comment #40)
> > Comment on attachment 481345 [details] [diff] [review] [details]
> > Progress Line Visual Style Update v05
> > 
> > Cancelling review for now since bug 602126 is probably going to require drastic
> > changes to this patch.
> 
> I don't think bug 602126 will require you to change this patch, since it seems
> like bug 602126 just involves the connecting state. Even if replacing the
> gradient with a PNG in that bug doesn't work, we could just replace the
> .progress-remainder background with an APNG when it's in the connecting state,
> then switch back to the original background once the progress meter starts
> moving.

You're right! I don't think that bug will affect this.

Comment 43

[Dão Gottwald [:dao]]

wontfix per bug 602964