Closed Bug 953433 Opened 10 years ago Closed 10 years ago

download button using two different colors after completing download


(Firefox for Metro Graveyard :: Downloads, defect, P2)

Windows 8.1


(firefox28 verified, firefox29 verified)

Firefox 29
Tracking Status
firefox28 --- verified
firefox29 --- verified


(Reporter: kjozwiak, Assigned: azasypkin)



(Whiteboard: [release28] [defect] p=0)


(4 files, 1 obsolete file)

When a user is downloading something, the current part of the download indicator will be a darker blue while the already downloaded portions will turn light blue. The issue is once the download is completed, you'll have a button with two different colors on both sides making the button look really off.

I think that once the download is completed, the entire download button should have a smooth transition and change the entire button light blue so its consistent.

Yuan, thoughts?

- Attached a screenshot to illustrate the issue

Steps to reproduce the issue:

1) Open Firefox Metro
2) Download anything from a website (I downloaded VLC)
3) Once the download is completed, you'll notice that the button has two different colors (making it look 50/50)

Current Behavior:

- Once a download is completed, the download button will have two different colors. Once side of the button will be light blue while the other side will be a dark blue

Expected Behavior:

- Once the download is completed, the button should turn to the same color in a smooth transition.

Used the following builds to find the issue:
Flags: needinfo?(ywang)
No longer blocks: 83808
I don't think shorlander specified colors of the download ring in his visual specs. 

Personally, I agree with Kamil that a single blue color suits better with windows 8 UI style.

Defer to Michael to make a final visual call on whether to keep two colors or one.
Flags: needinfo?(ywang) → needinfo?(mmaslaney)
This is the result of the gradient we added in bug 943201. Now, the progress circle image is clipped and rotated to progressively reveal

.. At 100%, the entire image is revealed. I think to get both the in-progress gradient and a solid "completed" ring we'll need another image. We could probably put it in (next to) - we can swap out the progress image with this new image at [progress=100]. We might be able to do this either in CSS or failing that in the binding code.
Attached file
Agreed, we need a finished state that actually affords the download as being finished.

I propose an all blue finished state at the end of each download with a scaling/opacity transition (see keynote file), much like we see in the traditional desktop experience. By doing this, I feel as though we will make the download button seem more click/touchable.
Flags: needinfo?(mmaslaney)
Whiteboard: [triage] [defect] p=0 → [beta28] [defect] p=0
Whiteboard: [beta28] [defect] p=0 → [release28] [defect] p=0
Taking this. I'll get the new asset in there and download-completed state. The expanding concentric ring effect may not happen this time around but I'll take a look at it
Assignee: nobody → sfoster
Blocks: metrov1it22
No longer blocks: metrov1backlog
Quicktime export of the keynote file showing the transition to finished.
Assignee: sfoster → azasypkin
Blocks: metrov1backlog
No longer blocks: metrov1it22
(In reply to Sam Foster [:sfoster] from comment #5)
> Created attachment 8359904 [details]
> Quicktime export of the keynote file showing the transition to finished.

Awesome, looks really good. Really easy to tell that the download has been completed.

Any idea's on how it will look with two simultaneous downloads at the same time? Will there be two "flashes" as each download is completed? Currently we only show the progress of a single download even if two are occurring at the same time.
Attached patch download button patch v1.diff (obsolete) — Splinter Review
Attached initial version of the patch. It doesn't have any visual effects yet (like expanding concentric ring effect or smooth transition to completed state). Duplicated the same assets for hover and active states until Michael provides it. Manipulating with "list-item-image" to reuse CSS for hover\active styles.

We probably should fire "completed" effect for every completed download if there are many (like desktop version does), but toggle completed state only once everything is downloaded.
Attachment #8360455 - Flags: review?(sfoster)
Comment on attachment 8360455 [details] [diff] [review]
download button patch v1.diff

Review of attachment 8360455 [details] [diff] [review]:

Looks great. I agree that the way we treat multiple downloads needs review. Could you file a bug on that for follow-up post v1. Also, lets get a separate bug for the circles effect. Its polish, but we may be able to get to that before release. This patch is good to go though with the quote nit fixed. When its updated, you can add the checkin-needed keyword to this bug and I or someone else can land it for you.

::: browser/metro/theme/browser.css
@@ +775,5 @@
>  #download-progress {
>    list-style-image: url(chrome://browser/skin/images/navbar-download.png);
>  }
> +#download-progress[progress='100'] {

nit: lets use " for these quotes throughout for consistency - they get changed to that in the CSSOM anyhow.
Attachment #8360455 - Flags: review?(sfoster) → review+
Thanks, Sam! Fixed quotes and compressed png files a bit.
Attachment #8360455 - Attachment is obsolete: true
Keywords: checkin-needed
Blocks: metrov1it22
No longer blocks: metrov1backlog
Priority: -- → P2
QA Contact: jbecerra
Keywords: checkin-needed
Whiteboard: [release28] [defect] p=0 → [release28] [defect] p=0[fixed-in-fx-team]
Blocks: 960489
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [release28] [defect] p=0[fixed-in-fx-team] → [release28] [defect] p=0
Target Milestone: --- → Firefox 29
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0

Verified as fixed on latest nightly (build ID: 20140119030202).
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Build ID: 20140122004004

Also verified as fixed on latest aurora with several downloads.
You need to log in before you can comment on or make changes to this bug.