Progress line indicator should match OS colour scheme

RESOLVED WONTFIX

Status

()

Firefox
Theme
RESOLVED WONTFIX
8 years ago
6 years ago

People

(Reporter: [not reading bugmail], Assigned: shorlander)

Tracking

({polish})

Trunk
All
Windows 7
polish
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

(Whiteboard: [see comment 7])

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

8 years ago
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.

Updated

8 years ago
Component: General → Location Bar
QA Contact: general → location.bar
Version: unspecified → Trunk
(Reporter)

Comment 1

8 years ago
mockup for background tab: attachment 425750 [details]

mockup for foreground tab: attachment 470022 [details]
Blocks: 597307
OS: Windows 7 → All
Hardware: x86 → All
Agreed should be green imo

Comment 3

8 years ago
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

8 years ago
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.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true

Comment 5

8 years ago
(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.
Created attachment 477026 [details]
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;
}
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

8 years ago
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?
OS: All → Windows 7
(Reporter)

Comment 9

8 years ago
Updating summary to match.
Summary: Progress "Line" indicator for loading tabs should be *Green* not Blue → [Win7] Progress "Line" indicator for loading tabs should be *Green* not Blue
Whiteboard: [see comment 7]
(Reporter)

Updated

8 years ago
Summary: [Win7] Progress "Line" indicator for loading tabs should be *Green* not Blue → [Windows] Progress "Line" indicator for loading tabs should be *Green* not Blue
>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.
Assignee: nobody → shorlander
blocking2.0: ? → final+
Keywords: polish
Summary: [Windows] Progress "Line" indicator for loading tabs should be *Green* not Blue → Progress line indicator should match OS colour scheme
(Assignee)

Comment 11

8 years ago
Created attachment 478187 [details] [diff] [review]
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.
Attachment #478187 - Flags: review?(dao)
(Assignee)

Comment 12

8 years ago
Created attachment 478189 [details]
Screenshot of Patch v01
Yes! Green looks much nicer and it's much more visible.
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

8 years ago
(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)

Updated

8 years ago
Depends on: 597353
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.
Component: Location Bar → Theme
QA Contact: location.bar → theme
Another minor note on the patch: -moz-border-radius is an alias, Gecko supports the standard border-radius notation as of recently.
(Assignee)

Comment 18

8 years ago
Created attachment 478262 [details] [diff] [review]
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!
Attachment #478187 - Attachment is obsolete: true
Attachment #478262 - Flags: review?(dao)
Attachment #478187 - Flags: review?(dao)

Updated

8 years ago
Flags: in-litmus?(abillings)
If this gets review it's got my permission to go in for beta7.
(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.
(Assignee)

Comment 21

8 years ago
(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!
(Assignee)

Comment 22

8 years ago
Created attachment 478497 [details] [diff] [review]
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.
Attachment #478262 - Attachment is obsolete: true
Attachment #478497 - Flags: review?(dao)
Attachment #478262 - Flags: review?(dao)
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.
blocking2.0: final+ → ?
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?
Attachment #478497 - Flags: review?(dao)
Marking blocking. The amount of time I've spent squinting at the progress line so far is tangible, and should not be.
blocking2.0: ? → betaN+
If the patch gets reviewed in time, renominate and we'll move it to beta7+. Not before then, though.
(Assignee)

Comment 27

8 years ago
(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.
blocking2.0: betaN+ → ?
blocking2.0: ? → betaN+
(Assignee)

Comment 28

8 years ago
Created attachment 480213 [details] [diff] [review]
Progress Line Visual Style Update v04

Updated to tip and use scaleX(-1) for RTL.
Attachment #478497 - Attachment is obsolete: true
(Assignee)

Updated

8 years ago
Attachment #480213 - Flags: review?(dao)

Updated

8 years ago
Duplicate of this bug: 601244
The PL color on Ubuntu is wrong, orange should be used.
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?
blocking2.0: betaN+ → beta7+
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
Attachment #480213 - Flags: review?(dao)
Does any of this mean we'll be having the green progress lines like the ones in the mockup?

Comment 34

8 years ago
(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.
(Assignee)

Comment 35

8 years ago
(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 :)
(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.
(Assignee)

Comment 37

8 years ago
Created attachment 481345 [details] [diff] [review]
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.
Attachment #480213 - Attachment is obsolete: true
Attachment #481345 - Flags: review?(dao)
(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?
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 )
(Assignee)

Comment 40

8 years ago
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.
Attachment #481345 - Flags: review?(dao)

Comment 41

8 years ago
(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.
(Assignee)

Comment 42

8 years ago
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.
Attachment #481345 - Flags: review?(dao)
wontfix per bug 602964
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX

Updated

8 years ago
Attachment #481345 - Flags: review?(dao)
Flags: in-litmus?(abillings) → in-litmus?
You need to log in before you can comment on or make changes to this bug.