Closed Bug 1301384 Opened 8 years ago Closed 8 years ago

Unify the progress bar styling in the Downloads Panel across platforms

Categories

(Firefox :: Downloads Panel, defect)

Product:
Firefox
Component:
Downloads Panel
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 53
Tracking Flags:
Tracking Status
firefox52 + verified
firefox53 --- verified

People

(Reporter: Paolo, Assigned: rexboy)

References

(Depends on 1 open bug)

Details

(Whiteboard: [CHE-MVP])

Attachments

(5 files, 2 obsolete files)

Progress Bar.jpg
79.71 KB, image/jpeg
Details
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.
58 bytes, text/x-review-board-request
rexboy
: review+
jcristau
: approval-mozilla-aurora+
Details
high contrast screenshot
18.37 KB, image/png
Details
high contrast screenshot 2
98.19 KB, image/png
Details
Bug 1301384 - Part 2 - Unify Progressbar across different OSs for download panels.
58 bytes, text/x-review-board-request
rexboy
: review+
jcristau
: approval-mozilla-aurora+
Details 
The visual redesign of the Downloads Panel includes a revised appearance of the progress bar shown when a download is in progress.

The new progress bar will be thinner on all platforms, and this allow us to revise the margins and item heights at the same time.

The summary section in the panel footer can also be updated to match the flatter appearance of the new progress bar on Windows 7.
AFAIK we're currently using native progress bars that look both integrated on polished across platforms and OS themes and come with goodies like progress animation on Windows. You really want to drop this just to make the progress bars thinner?

Also, is this the wrong patch?
If this is just about the height of the progress bar, it may be possible to keep the standard appearance but override the min-height (Windows) / height (Mac) from progressmeter.css.
(In reply to Dão Gottwald [:dao] from comment #2)
> AFAIK we're currently using native progress bars that look both integrated
> on polished across platforms and OS themes and come with goodies like
> progress animation on Windows. You really want to drop this just to make the
> progress bars thinner?

This was discussed by Carol and Stephen and we simply want to change the progress bar appearance in the Downloads Panel to a different one as a visual design choice. Asking Stephen or Carol to confirm.

I've only seen the mockups in attachment 8784314 [details], not sure if they are the exact final appearance but personally I find that the flatter and thinner style that uses our official blue color from the Style Guide works much better with our redesigned download item, especially on Windows 7 and Linux.

This part 1 is here because I think removing the custom Downloads Summary styling on Windows 7 works together with giving the progress bar its new appearance. You've surely noticed it includes some small cleanups that could be separated into their own patch, but I didn't think they were worth a separate patch.
Flags: needinfo?(shorlander)
Flags: needinfo?(chuang)
(In reply to :Paolo Amadini from comment #4)
> (In reply to Dão Gottwald [:dao] from comment #2)
> > AFAIK we're currently using native progress bars that look both integrated
> > on polished across platforms and OS themes and come with goodies like
> > progress animation on Windows. You really want to drop this just to make the
> > progress bars thinner?
> 
> This was discussed by Carol and Stephen and we simply want to change the
> progress bar appearance in the Downloads Panel to a different one as a
> visual design choice. Asking Stephen or Carol to confirm.
> 
> I've only seen the mockups in attachment 8784314 [details], not sure if they
> are the exact final appearance but personally I find that the flatter and
> thinner style that uses our official blue color from the Style Guide works
> much better with our redesigned download item, especially on Windows 7 and
> Linux.

Hard-coding some particular shade of blue is not the way to go anyway; you should be using the Highlight color, at least on Linux and non-default Windows themes.

Windows default themes are an interesting case, because Highlight is generally blue there and progress bars are generally green (and they animate to give better feedback, as already mentioned). I'm not sure why you think a custom blue would work better there. I understand that if you're coming from Mac for instance and look at the panel in isolation, the Windows 7 progress bar may look odd to you. But for people using Windows 7 every day, it's the other way around.
(In reply to Dão Gottwald [:dao] from comment #5)
> Hard-coding some particular shade of blue is not the way to go anyway; you
> should be using the Highlight color, at least on Linux and non-default
> Windows themes.

Granted, we should use platform colors for non-default themes and I guess we can do the same for Linux. We have examples where we've already done this in our recent Control Center work.

For default themes the Style Guide specifies the shade of blue to use, which will be consistent with our new buttons, but I'll let the visual design team specify how to proceed exactly.

> Windows default themes are an interesting case, because Highlight is
> generally blue there and progress bars are generally green (and they animate
> to give better feedback, as already mentioned). I'm not sure why you think a
> custom blue would work better there.

I'll let Stephen comment on the color choice.

> I understand that if you're coming from
> Mac for instance and look at the panel in isolation, the Windows 7 progress
> bar may look odd to you. But for people using Windows 7 every day, it's the
> other way around.

I use Windows 7 every day and the progress bar with the Firefox color looks much better to me than the platform one, in the context of the redesigned Downloads Panel, but it's a personal observation and again we should defer to visual design.
Attached image Progress Bar.jpg — 
Hi,
Just had a discussion with Stephen last night about the progress bar style.
The attachment is the new design with different download state. The bar is a little thicker than what we have on OSX now. I want to apply this style to All OSX/Windows/Linux
The buffering state is using blue -white gradient.
the pause state is a gray color and the blue is download in progress.
I will update the visual spec soon on Bug 1269956.
Flags: needinfo?(chuang)
(In reply to Carol Huang [:Carol] from comment #7)
> I want to apply this style to All OSX/Windows/Linux

The blue is not gonna work well on Linux and non-default Windows themes (i.e. mostly high-contrast themes these days). You can think of Gtk themes on Linux as random color generators, so in some cases the blue might be hard to see and in others it might just look out of place.

Anyway, ignoring Linux and non-default Windows for now...

Your mockup looks like it's basically adopting the native Windows 10 style except for the color. Two questions:

1. Why the color change? Your mockup is mostly gray except for the progress bar, so it's not clear that the native green wouldn't work just as well. Even if the blue works somehow better, is that upside big enough to justify the inconsistency with the OS?

2. Why port the Windows 10 style to other OSes including older versions of Windows? I personally (having already moved to Windows 10) do think it looks nice. Some users of older versions might feel the same and welcome the change, but others will likely oppose it for not integrating with their system. (FWIW, most users won't really care either way.) From an engineering point of view, unifying the style across platforms doesn't help at all, because this requires reimplemented the styling including animations and stuff. We already get the native appearance for free.
Comment on attachment 8789372 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

https://reviewboard.mozilla.org/r/77626/#review76894

Thanks for removing the redundant css rules for #downloadsSummary and cursor since #downloadsSummary is not possible to be clicked.
So I think @keyfocus@ for #downloadsSummary should be considered as well. We can discuss @keyfocus@ for #downloadsSummary part if needed.

This patch looks good to me.

::: browser/themes/windows/downloads/downloads.css:9
(Diff revision 1)
> -      }
> -    }
> -  }
> -}
> -
>  @keyfocus@ #downloadsSummary:focus,

Since #downloadsSummary should not be possible to be focused via keyboard [1], I suppose that @keyfocus@ rules for #downloadsSummary can be removed.

If this is worth to remove, please remove [2] in OSX and [3] in linux as well.

[1] http://searchfox.org/mozilla-central/source/browser/components/downloads/content/downloads.css#41
[2] http://searchfox.org/mozilla-central/source/browser/themes/osx/downloads/downloads.css#13
[3] http://searchfox.org/mozilla-central/source/browser/themes/linux/downloads/downloads.css#9
Attachment #8789372 - Flags: review?(selee) → review+
(In reply to Dão Gottwald [:dao] from comment #8)
> (In reply to Carol Huang [:Carol] from comment #7)
> > I want to apply this style to All OSX/Windows/Linux
> 
> The blue is not gonna work well on Linux and non-default Windows themes
> (i.e. mostly high-contrast themes these days). You can think of Gtk themes
> on Linux as random color generators, so in some cases the blue might be hard
> to see and in others it might just look out of place.
> 
> Anyway, ignoring Linux and non-default Windows for now...
> 
> Your mockup looks like it's basically adopting the native Windows 10 style
> except for the color. Two questions:
> 
> 1. Why the color change? Your mockup is mostly gray except for the progress
> bar, so it's not clear that the native green wouldn't work just as well.
> Even if the blue works somehow better, is that upside big enough to justify
> the inconsistency with the OS?
> 
> 2. Why port the Windows 10 style to other OSes including older versions of
> Windows? I personally (having already moved to Windows 10) do think it looks
> nice. Some users of older versions might feel the same and welcome the
> change, but others will likely oppose it for not integrating with their
> system. (FWIW, most users won't really care either way.) From an engineering
> point of view, unifying the style across platforms doesn't help at all,
> because this requires reimplemented the styling including animations and
> stuff. We already get the native appearance for free.

From UX’ point of view, we want to give the user the consistent experiences across different OS. So right now we’re trying to unify the look and the component for Firefox. The blue color I’m using is from our Firefox style guide for the highlight.

For the high contrast theme, I’m working with Sean to see if there’s any good solution to keep the visibility of the progress bar when switching to different theme.

I’ll let Paolo comment about the engineer side on unifying styles across platform. Thanks!
Flags: needinfo?(paolo.mozmail)
(In reply to Carol Huang [:Carol] from comment #10)
> From UX’ point of view, we want to give the user the consistent experiences
> across different OS. So right now we’re trying to unify the look and the
> component for Firefox. The blue color I’m using is from our Firefox style
> guide for the highlight.

How exactly do native progress bars make for an inconsistent experience? What problem are you trying to solve here?

I think we need to strike a balance between establishing a visual identity that represents Firefox and platform integration. If you ignore the latter, Firefox will look inconsistent with its surrounding.
Flags: needinfo?(chuang)
(In reply to Carol Huang [:Carol] from comment #10)
> I’ll let Paolo comment about the engineer side on unifying styles across
> platform. Thanks!

From the engineering side, we should do what it takes to implement the style that is eventually decided upon by the user experience team, because I don't think the request to unify the style is unreasonable from an implementation perspective.

In fact, the unified style is probably very simple to implement. We can take the indicator code as reference, we also need simpler colors and don't even need to override some of the properties like "min-width":

https://dxr.mozilla.org/mozilla-central/rev/62f79d676e0e11b3ad59a5425b3ebb3ec5bbefb5/browser/themes/windows/downloads/indicator.css#184-217

I'm not sure if we need to do something special to implement the undetermined state.

With regard to comment 11, personally I think the new style fits much better with the immediate surroundings given by the new style of the download items, but I'll let the UX team confirm that we want to go ahead with this change.
Flags: needinfo?(paolo.mozmail)
(In reply to Sean Lee [:seanlee][:weilonge] from comment #9)
> Thanks for removing the redundant css rules for #downloadsSummary and cursor
> since #downloadsSummary is not possible to be clicked.

Thanks for the review!

> Since #downloadsSummary should not be possible to be focused via keyboard
> [1], I suppose that @keyfocus@ rules for #downloadsSummary can be removed.

Actually, this element can still be focused with the keyboard if the mouse is not over it. However, when testing I noticed that I can tab through the hidden buttons while the mouse is over the footer. Probably "-moz-user-focus: ignore;" should be added to the individual buttons to fix this issue. Thanks for pointing out the keyboard case!
(In reply to :Paolo Amadini from comment #12)
> (In reply to Carol Huang [:Carol] from comment #10)
> > I’ll let Paolo comment about the engineer side on unifying styles across
> > platform. Thanks!
> 
> From the engineering side, we should do what it takes to implement the style
> that is eventually decided upon by the user experience team, because I don't
> think the request to unify the style is unreasonable from an implementation
> perspective.
> 
> In fact, the unified style is probably very simple to implement. We can take
> the indicator code as reference, we also need simpler colors and don't even
> need to override some of the properties like "min-width":
> 
> https://dxr.mozilla.org/mozilla-central/rev/
> 62f79d676e0e11b3ad59a5425b3ebb3ec5bbefb5/browser/themes/windows/downloads/
> indicator.css#184-217
> 
> I'm not sure if we need to do something special to implement the
> undetermined state.

If the bar should animate in the undetermined state, you'll have to implement that.

I also assumed you'd copy (i.e. re-implement) the native animation for the determined state, because it's useful feedback there too. Is that not part of the plan? This would be a UX regression.
(In reply to Dão Gottwald [:dao] from comment #11)
> (In reply to Carol Huang [:Carol] from comment #10)
> > From UX’ point of view, we want to give the user the consistent experiences
> > across different OS. So right now we’re trying to unify the look and the
> > component for Firefox. The blue color I’m using is from our Firefox style
> > guide for the highlight.
> 
> How exactly do native progress bars make for an inconsistent experience?
> What problem are you trying to solve here?
> 
> I think we need to strike a balance between establishing a visual identity
> that represents Firefox and platform integration. If you ignore the latter,
> Firefox will look inconsistent with its surrounding.

I agree it's a balancing act between native vs. Firefox's own visual identity. It's a spectrum that we have found ourselves closer to either end of at various times.

The current situation with Windows 10 is that there are between 4 and 5 different types of progress bars. There are what I would consider the "new" progress bars that are flat. But there are two types of those, the kind that grab the system Highlight color and the custom ones like Edge uses (always blue). There is also the older Windows 7 style green version that we get. I have seen a few variations of that also.

Given the current state, Windows 10 and macOS are pretty similar with regards to styling (in this area at least). I don't think what we have proposed would be jarring on either platform. And maybe more importantly I don't think it will be jarring in the context of our panels.

The benefit is that we can define the size and shape of these without relying on the shifting platform styling that is in itself not always internally consistent.

This perhaps doesn't work quite as well on Linux where the environment is largely variable, or on older versions of Windows that doesn't match the new aesthetic. It might be nice to align on elements like color while still being able to define the size and shape, but we don't get that information AFAIK.
Flags: needinfo?(shorlander)
Whiteboard: [CHE-MVP]
Sorry for interrupt, Paolo I saw you've been working on a patch here while nobody is assigned. May I assume you will take this one later, or you expect someone from our project to do? Thanks.
Flags: needinfo?(paolo.mozmail)
(In reply to Wesly Huang (Firefox EPM) from comment #16)
> Sorry for interrupt, Paolo I saw you've been working on a patch here while
> nobody is assigned. May I assume you will take this one later, or you expect
> someone from our project to do? Thanks.

This is just something I wanted to land together with the other work in this bug. I think Sean or Rex would implement the rest of the unified progress bar styling across platforms including the undetermined state animation, according to the recent update to the visual design specification.
Flags: needinfo?(paolo.mozmail)
Assignee: nobody → rexboy
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

I made a patch but without a good idea of how to get a good structure for these changes.
Basically I only need some css style applied on default progressmeter to accomplish the required visual; but since the default style for progressmeter still presents, I have to override those rules contributed from progressmeter.css on osx/windows and global.css under linux, creating unnecessary implied dependency.

One solution that came to me is applying a type="unified" and prevent those default rules from it, but in that way, we need to append several :not() on default rules of progressmeter. I'm not sure if there are better ways to do that.

Paolo would you give me some advice about it? The patch is workable but there are still some detail need to be confirmed with visual (e.g. the border style) so they may be changed before sending review?.
Attachment #8802444 - Flags: feedback?(paolo.mozmail)
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

(In reply to KM Lee [:rexboy] from comment #19)
> Basically I only need some css style applied on default progressmeter to
> accomplish the required visual; but since the default style for
> progressmeter still presents, I have to override those rules contributed
> from progressmeter.css on osx/windows and global.css under linux, creating
> unnecessary implied dependency.

There is some related discussion in bug 1288747 which also has analogies to your suggestion, but for the moment this is the way this is supposed to work so your patch is on the right track.

> Paolo would you give me some advice about it? The patch is workable but
> there are still some detail need to be confirmed with visual (e.g. the
> border style) so they may be changed before sending review?.

Looks mostly good to me. When you have implemented the final visuals, you can ask Dão for the review of the code changes.

I'm not quite sure how to test the undetermined progress bar during normal browsing, do you have a download link I can use?
Attachment #8802444 - Flags: feedback?(paolo.mozmail) → feedback+
Thank you Paolo!
I'll try to stick to current implementation then.

Google drive shows unknown size to me so I usually use it for testing. You may try it here (The file is just a copy of Nightly build).
https://drive.google.com/a/mozilla.com/file/d/0BxETpo72mJCSWjR5ci1rUEp6VUU/view?usp=sharing
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

I tried let the common-styled progressmeter support both Download Panel and All Downloads View. So a progressmeter.inc.css is created for the common-styled progressmeter, but I'm not quite sure if the way I include it is appropriate.
Besides, the pause state can't be detected by the progressmeter itself, so the style for pause state is still addressed separately on each view.

Dão would you mind review this patch and give me some advices?
Attachment #8802444 - Flags: review?(dao+bmo)
For unifying the style, the visual spec is on Bug 1269956. 
I will remove my ni for now.
Flags: needinfo?(chuang)
Hi Dao:
Just want to confirm if you're comfortable for reviewing this patch. If you're not able to review it I can try changing a reviewer. Thanks!
Flags: needinfo?(dao+bmo)
I can take this review if Dão still does not have the time, now that I've finished most of the Permissions Notification project.

[Tracking Requested - why for this release]:
We would like to deliver the MVP for the Downloads Panel visual redesign in Firefox 52. The project bar restyling is a required part of the redesign.
tracking-firefox52: --- → ?
Summary: Unify the spacing and the progress bar styling in the Downloads Panel across platforms → Unify the progress bar styling in the Downloads Panel across platforms
Blocks: 1269957
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

- You need to use platform colors such as Highlight as mentioned earlier.

- As mentioned earlier as well, Windows has an animation even for "determined" progress bars, so that the user gets feedback even if progress is slow. It would be good to keep this for UX parity.

- Please don't add the "common" class. Instead, just style .downloadProgress directly. We can move this code later in case we want to use it in other contexts.
Flags: needinfo?(dao+bmo)
Attachment #8802444 - Flags: review?(dao+bmo) → review-
Thank you Dao for the advices!

For some of the visual issues I'll make a double check with visual and update the patch again. (Or raise some discussion here)
Found the highlight color is just a very deep one and I'm not sure if it meets visual's intention. Or we need to replace it for non-default themes (Not sure if it's easy).
Based on previous comments I keep the color fixed for windows default and mac, while Highlight color are applied in other cases.
Tested on mac/linux/windows 10/windows high contrast.
I'll make a check with visual and send review soon.
(In reply to Dão Gottwald [:dao] from comment #28)
> Comment on attachment 8802444 [details]
> Bug 1301384 - Unify Progressbar across different OSs for download panels.
> 
> - You need to use platform colors such as Highlight as mentioned earlier.
> 
> - As mentioned earlier as well, Windows has an animation even for
> "determined" progress bars, so that the user gets feedback even if progress
> is slow. It would be good to keep this for UX parity.
Hi Dão!

For the new design, we won't have the shinny lighting animation like on Windows for "determined" progress bars. The remaining time and downloaded files size will indicate it's still in progress. 
Let me know if you have other concerns. Thanks!

> - Please don't add the "common" class. Instead, just style .downloadProgress
> directly. We can move this code later in case we want to use it in other
> contexts.
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

Updated based on reviewer and visual's input, mainly:

1. we have the color to Highlight(Progressing) and GrayText(Paused); but under mac and default-theme of windows, we set to a color specified by visual spec. (by comment 6 if I understand correctly)
2. remove common style.
3. I added a property called progresspaused (which is inherited by progressbar as paused) to explicitly indicate the progressbar need to be set to paused style so that we can set the paused style in commonProgressbar independently. 
4. The animation is kept on only undetermined mode based on visual's input.

Dao may you help take a look on this revised patch. Thanks!
Attachment #8802444 - Flags: review?(dao+bmo)
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

- please move the code from browser/themes/shared/commonProgressmeter.inc.css to somewhere in browser/themes/shared/downloads/, e.g. browser/themes/shared/downloads/progressmeter.inc.css

- have you tested the colors used in .downloadProgress[mode="undetermined"] > .progress-bar and .downloadProgress > .progress-remainder in High Contrast mode?

- RGBA(...) should be rgba(...)

- margin: 2px 12px 2px 6px; and border-width: 1px 1px 1px 0; look like they assume LTR layout. Please use margin-inline-start, margin-inline-end, border-inline-start-width and border-inline-end-width

- border-width: 1px 1px 1px 1px; should be border-width: 1px;

- please rename progressSlideX to downloadProgressSlideX
Attachment #8802444 - Flags: review?(dao+bmo) → review-
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

I replace the remaining fixed color of .downloadProgress > .progress-remainder by system color (ButtonShadow and ButtonFace).

 but I'm a little bit confused now. Should we replace every color by system color or variable? Because if I try to replace every color by system color, it may sometimes be difficult to fulfill the intention or requirement on visual spec (Or I need to create another variable for those case?).  Actually I almost need to discuss every color with visual team again despite that we have a detailed visual spec there already. Do we have some rule of thumb for picking allowed color? For example they will be good if they looks ok on some indicative themes like High Contrast theme.

And Dao may you take a look on the patch again? I'll attach some screenshot on high contrast theme later.
Attachment #8802444 - Flags: review?(dao+bmo)
Attached image high contrast screenshot (obsolete) — 

    
    

    
  


  

        Attachment #8814357 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

+    if (this.download.canceled && this.download.hasPartialData) {

I'm not sure I understand this. Does canceled && hasPartialData really translate to "paused"?

+      this.element.setAttribute("progresspaused", 'true');

Please use double quotes.

+++ b/browser/themes/shared/downloads/commonProgressmeter.inc.css

Please rename this to just progressmeter.inc.css.

+  margin-block-start: 2px;
+  margin-block-end: 2px;

We don't support vertical layout in the Firefox UI, so you might as well use margin-top and margin-bottom. If someday we support vertical layout, we'll have to rewrite lots of stuff anyway.

+  background-size: 400px 100%;

+    background-position: 400px 0;

Where does this number come from? Can you use 100% instead of 400px?

Looks good otherwise.

        Attachment #8802444 -
        Flags: review?(dao+bmo)

    
    

    
  
(In reply to Dão Gottwald [:dao] from comment #42)
> Comment on attachment 8802444 [details]
> Bug 1301384 - Unify Progressbar across different OSs for download panels.
> 
> +    if (this.download.canceled && this.download.hasPartialData) {
> 
> I'm not sure I understand this. Does canceled && hasPartialData really
> translate to "paused"?
> 
Well, I just referenced this condition from [1] and maybe you can take a look there.
I'll keep that for now and let you decide if I need to make further changes.

> +  background-size: 400px 100%;
> 
> +    background-position: 400px 0;
> 
> Where does this number come from? Can you use 100% instead of 400px?
> 
You reminded me that I made that change when trying making running light in determined mode (Since the length of area is variable).
But since we'll not implement moving light in determined mode based on visual's input, I can change it back to percentage. But make it 200% or some percentage larger than 100% to make the background movable is required.


[1] https://dxr.mozilla.org/mozilla-central/source/browser/components/downloads/DownloadsViewUI.jsm#208

    
    

    
      
  

    
    

    
  
(In reply to KM Lee [:rexboy] from comment #43)
> (In reply to Dão Gottwald [:dao] from comment #42)
> > +    if (this.download.canceled && this.download.hasPartialData) {
> > 
> > I'm not sure I understand this. Does canceled && hasPartialData really
> > translate to "paused"?
> > 
> Well, I just referenced this condition from [1] and maybe you can take a
> look there.

If you want to match that code, you should add this.download.stopped as a condition.

    
    

    
  
  /* for overriding rules in progressmeter.css */
  -moz-appearance: none;
  border: 0;

nit: use 'boder-style: none;' instead

  min-width: 128px;
  min-height: 8px;

If these are only for overriding progressmeter.css, can you use 'initial' instead of these px values?

another nit: use 'transparent' instead of 'rgba(255,255,255,0)'

    
    

    
      
  

    
    

    
  
Updated & tested again. I did missed the first if clause and thanks for addressing that.
May you take a look again, thanks!

        Attachment #8802444 -
        Flags: review?(dao+bmo) → review+

    
    

    
  
Thank you Dão!
Keywords: checkin-needed

    
    

    
      
  

    
    

    
      
  

    
    

    
  
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

Carrying r+ from comment 9. Seems it conflicts with the latest source. I just rebased it from Paolo's patch without any additional change.

        Attachment #8802444 -
        Flags: review?(selee) → review+

    
    

    
  
Comment on attachment 8815990 [details]
Bug 1301384 - Part 2 - Unify Progressbar across different OSs for download panels.

Carrying r+ from Dão between comment 48 and comment 49.

        Attachment #8815990 -
        Flags: review?(dao+bmo) → review+

        Attachment #8789372 -
        Attachment is obsolete: true

    
    

    
  
Tagging checkin-needed.

Note the part 1 sent by me is actually the same with Paolo's patch, with rebasing to the latest master.
Keywords: checkin-needed

    
    

    
  
Please ensure that the patches are flagged as r+ in MozReview so Autoland can push them.
Keywords: checkin-needed

    
    

    
  
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5aed64199128
Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier. r=seanlee
https://hg.mozilla.org/integration/mozilla-inbound/rev/50d9eab50fc0
Part 2 - Unify Progressbar across different OSs for download panels. r=dao

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/5aed64199128
https://hg.mozilla.org/mozilla-central/rev/50d9eab50fc0
Status: NEW → RESOLVED
Closed: 8 years ago

          status-firefox53:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53

    
  
Depends on: 1322819

    
    

    
  
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

Approval Request Comment: See other attachment, should be uplifted together.

        Attachment #8802444 -
        Flags: approval-mozilla-aurora?

    
    

    
  
Comment on attachment 8815990 [details]
Bug 1301384 - Part 2 - Unify Progressbar across different OSs for download panels.

Approval Request Comment
[Feature/Bug causing the regression]: Downloads Panel Redesign
[User impact if declined]: Inconsistent panel design
[Is this code covered by automated tests?]: No, front-end styles only
[Has the fix been verified in Nightly?]: Landed without reported regressions
[Needs manual test from QE? If yes, steps to reproduce]: 
[List of other uplifts needed for the feature/fix]: Bug 1269957, once ready.
[Is the change risky?]: Low risk.
[Why is the change risky/not risky?]: Style changes are limited to this feature.
[String changes made/needed]: None

        Attachment #8815990 -
        Flags: approval-mozilla-aurora?

    
    

    
  
[Needs manual test from QE? If yes, steps to reproduce]:

Start a medium-length download on Windows, Linux, and Mac OS X, using all theme variants like high contrast mode, and check that the progress bar is visible and the style is consistent in the Downloads Panel.

    
    

    
  
Comment on attachment 8802444 [details]
Bug 1301384 - Part 1 - Remove special styling for the Downloads Summary on Windows 7 and earlier.

download summary styling update for aurora52

        Attachment #8802444 -
        Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

    
    

    
  
Comment on attachment 8815990 [details]
Bug 1301384 - Part 2 - Unify Progressbar across different OSs for download panels.

download progress bar styling update for aurora52

        Attachment #8815990 -
        Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

    
    

    
  
[bugday-1301384] bug verified

    
    

    
  
I reproduced this issue using 53.0a1, build ID:20161218030213, on Windows 10 x64.
I can confirm this issue is fixed, I verified using Fx52.0a2, build ID: 20170113004016 and Fx53.0a1, build ID: 20170113030227, on Windows 10 x64, Mac OS X 10.12.3 and Ubuntu 14.04 LTS.

Cheers!

          status-firefox52:
          fixed → verified

          status-firefox53:
          fixed → verified

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: