Show the file's size in downloading menu

VERIFIED FIXED in Firefox 55

Status

()

P1
normal
VERIFIED FIXED
2 years ago
a year ago

People

(Reporter: xenos, Assigned: Paolo)

Tracking

52 Branch
Firefox 56
Points:
---

Firefox Tracking Flags

(firefox55 verified, firefox56 verified)

Details

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
Created attachment 8855827 [details]
showsize.PNG

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170302120751

Steps to reproduce:

I downloaded several files of the same name, so "myfile.pdf" get renamed by Firefox to "myfile(1).pdf", "myfile(2).pdf"


Actual results:

In the download menu, the file name is shown, but not the file size, meaning you have no clue whether you downloaded the same file twice or not.


Expected results:

Showing the file size (& download date) will make it way easier for users (inc. me) to know what they actually downloaded, without having to click "show all downloads". Plus, it makes the two view harmonized, which is always better IMO for UX (and for coder experience too: the download menu is the same as the "show all", but only has a LIMIT on it).

FF used to do so, it seems to have changed lately, in FF 50/51/52 (I don't exactly know)

Updated

2 years ago
Component: Untriaged → Downloads Panel
(Assignee)

Comment 1

2 years ago
Bryant, some users seems to use the file size to differentiate files with the same name in the Downloads Panel.

What do you think about this use case?
Flags: needinfo?(bmao)
(Reporter)

Comment 2

2 years ago
Created attachment 8864772 [details]
progressive-dl-ff.png

That same issue makes it also very hard to know that a "total size not known download" is progressing: you have to hover the name of the file (which I just discovered now) to know how much of the file has already been downloaded (and same goes for the download speed).

So when you humanly know the size of the file to be downloaded (here, I know that this zip of sources is about 20Mo, so I would know how much time there remains if I can see speed & downloaded size, same goes when you dl a song, a video, a picture, etc), it's hard to tell whether a hour remains, or few seconds, or minutes or so.
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1362746
Created attachment 8865826 [details]
Screen Shot 2017-05-09 at 7.43.52 AM.png

Hi Vincent,

For the case of the unknown size file that you mentioned, that should be a bug to fix. In our design, a user can see the download speed and downloaded size in the substring while downloading.
Flags: needinfo?(bmao)
(In reply to Vincent MONIER from comment #0)
> Created attachment 8855827 [details]
> showsize.PNG
> 
> User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101
> Firefox/52.0
> Build ID: 20170302120751
> 
> Steps to reproduce:
> 
> I downloaded several files of the same name, so "myfile.pdf" get renamed by
> Firefox to "myfile(1).pdf", "myfile(2).pdf"
> 
> 
> Actual results:
> 
> In the download menu, the file name is shown, but not the file size, meaning
> you have no clue whether you downloaded the same file twice or not.
> 
> 
> Expected results:
> 
> Showing the file size (& download date) will make it way easier for users
> (inc. me) to know what they actually downloaded, without having to click
> "show all downloads". Plus, it makes the two view harmonized, which is
> always better IMO for UX (and for coder experience too: the download menu is
> the same as the "show all", but only has a LIMIT on it).
> 
> FF used to do so, it seems to have changed lately, in FF 50/51/52 (I don't
> exactly know)

That's a good question. We defined download panel as the primary place to monitor the download progress, while downloads library is the place to archive the all the downloads and detail information about the downloads. 

Under this definition, a user should be able to tell each file's download status at a glance on the panel (not even need to read the text). That's why we only keep essential information under each download status, like showing downloaded size/total file size while downloading, and show only file name when it is completed. In most of the cases, the renamed mechanism should tell the duplicate downloaded by file name. But it did fall short to tell the downloads with same file name but different content. 

I wonder how common the use case is, can you tell me more about the scenario? Like what task you are doing? What website do you use to download? How many downloads are running at same time, and at what moment you what to the differentiate files (while downloading or after completed)?
(Reporter)

Comment 6

2 years ago
(In reply to Bryant Mao [:bryantmao] from comment #4)
> Created attachment 8865826 [details]
> Screen Shot 2017-05-09 at 7.43.52 AM.png
> 
> Hi Vincent,
> 
> For the case of the unknown size file that you mentioned, that should be a
> bug to fix. In our design, a user can see the download speed and downloaded
> size in the substring while downloading.

Well, I agree, but it's not what FF52.0x64 shows on Win7 (cannot try FF53 for now because workplace's network... meh!).


> download panel as the primary place to monitor the download progress, while downloads library is the place to archive

IMO, this is very confusing because it's not really splited in two like you say. If you do want to consider DL panel as the place to monitor DL in progress, then a finished-DL should be removed from that panel (it's no longer in progress, so it has nothing to do here). And that behavior would make it very hard to use downloads from UX side. So FF made a "half-split" to avoid this, and that "halfing" is quiet confusing because you have "same looking things with not same information & goal" (DL progress panel and DL archives looks *very* close, way too close to me to be considered as different things). Last, having information that "disappear" from the DL panel is quiet intriguing (the file's size is shown while DL is in progress, but it disappears *poof* once done?!)

Scnario:
• Downloading the same file in different version/revisions from a company-CMS: the same name is used for every revision (like it is on Git/Hg too) but the file size's allows you to know that "mydoc.pdf" and "mydoc(1).pdf" are different, and usually the heavier is the most recent one (you may download old rev first or new rev first so order in DL panel is not very reliable). 
• DL a video or a picture at different resolutions, file may then have the same name but the size tells you easily which one is 1080p and which is 480p
• I download a file (let's say a video), but it's not the right one I was looking for. So I seek in other websites, find another file named same, but if I see it's the same size, then it means it's still not the right file

It's even more obvious when you start the download, leave for a break, and come back afterward: "damn, which one was the new doc rev?" "Oupsy, who's the 480p version here?"

Comment 7

2 years ago
(In reply to :Paolo Amadini from comment #1)
> Bryant, some users seems to use the file size to differentiate files with
> the same name in the Downloads Panel.
> 
> What do you think about this use case?

i also use it, without seeing file size is a huge pain in the neck having to do extra clicks, this is definitely backwards. at least allow us to have the option to toggle this on/off with about:config.

Comment 8

2 years ago
(In reply to Vincent MONIER from comment #6)
> (In reply to Bryant Mao [:bryantmao] from comment #4)
> > Created attachment 8865826 [details]
> > Screen Shot 2017-05-09 at 7.43.52 AM.png
> > 
> > Hi Vincent,
> > 
> > For the case of the unknown size file that you mentioned, that should be a
> > bug to fix. In our design, a user can see the download speed and downloaded
> > size in the substring while downloading.
> 
> Well, I agree, but it's not what FF52.0x64 shows on Win7 (cannot try FF53
> for now because workplace's network... meh!).
> 
> 
> > download panel as the primary place to monitor the download progress, while downloads library is the place to archive
> 
> IMO, this is very confusing because it's not really splited in two like you
> say. If you do want to consider DL panel as the place to monitor DL in
> progress, then a finished-DL should be removed from that panel (it's no
> longer in progress, so it has nothing to do here). And that behavior would
> make it very hard to use downloads from UX side. So FF made a "half-split"
> to avoid this, and that "halfing" is quiet confusing because you have "same
> looking things with not same information & goal" (DL progress panel and DL
> archives looks *very* close, way too close to me to be considered as
> different things). Last, having information that "disappear" from the DL
> panel is quiet intriguing (the file's size is shown while DL is in progress,
> but it disappears *poof* once done?!)
> 
> Scnario:
> • Downloading the same file in different version/revisions from a
> company-CMS: the same name is used for every revision (like it is on Git/Hg
> too) but the file size's allows you to know that "mydoc.pdf" and
> "mydoc(1).pdf" are different, and usually the heavier is the most recent one
> (you may download old rev first or new rev first so order in DL panel is not
> very reliable). 
> • DL a video or a picture at different resolutions, file may then have the
> same name but the size tells you easily which one is 1080p and which is 480p
> • I download a file (let's say a video), but it's not the right one I was
> looking for. So I seek in other websites, find another file named same, but
> if I see it's the same size, then it means it's still not the right file
> 
> It's even more obvious when you start the download, leave for a break, and
> come back afterward: "damn, which one was the new doc rev?" "Oupsy, who's
> the 480p version here?"

completely agree, there are SO MUCH usefulness come with showing download size, and location where its from rather than having to go to library and check everything, by removing these info just create extra work for us. whoever's idea it is, certainly not very bright, a tool should be made to be more useful and more efficient, involving less click and less time taken, not the other way around.
(Reporter)

Comment 9

2 years ago
I just moved to FF 53.0.2x64 and it seems that the download menu now shows "size - source domain - date", and a "Fail" status for aborted/crashed downloads (so the same infos as the archive thing).

Seems perfect to me :)

Comment 10

2 years ago
(In reply to Vincent MONIER from comment #9)
> I just moved to FF 53.0.2x64 and it seems that the download menu now shows
> "size - source domain - date", and a "Fail" status for aborted/crashed
> downloads (so the same infos as the archive thing).
> 
> Seems perfect to me :)

thats good to know, well i am hoping they would revert these in 55.0a.1+ because the session restore thing in parent process are back again and only available in 55.0a.1.
(Assignee)

Comment 11

2 years ago
Bryant, do you have the information you need to make a decision on this?
Flags: needinfo?(bmao)
(Assignee)

Comment 12

2 years ago
Too late to fix in Firefox 54...
Flags: needinfo?(bmao)
(Assignee)

Comment 13

2 years ago
...but we still need a decision from Bryant.
Blocks: 1282662
Flags: needinfo?(bmao)
(Reporter)

Comment 14

2 years ago
(In reply to Vincent MONIER from comment #9)
> I just moved to FF 53.0.2x64 and it seems that the download menu now shows
> "size - source domain - date", and a "Fail" status for aborted/crashed
> downloads (so the same infos as the archive thing).
> 
> Seems perfect to me :)

Nevermind: either I've mistaking, or it got removed again in FF 53.0.3 64bits which only shows the file name once the download is completed, but not the file size / source domain / date / whatever
(Reporter)

Comment 15

2 years ago
(In reply to Vincent MONIER from comment #14)
> (In reply to Vincent MONIER from comment #9)
> > I just moved to FF 53.0.2x64 and it seems that the download menu now shows
> > "size - source domain - date", and a "Fail" status for aborted/crashed
> > downloads (so the same infos as the archive thing).
> > 
> > Seems perfect to me :)
> 
 Nevermind: either I've mistaking, or it got removed again in FF 53.0.3
 64bits which only shows the file name once the download is completed, but
 not the file size / source domain / date / whatever

And same when the file is being downloaded (I tried so with HeidiSQL from https://www.heidisql.com/download.php and same with any of my files like https://xenos.reinom.com/trading-cards/dragons-prototype.png )
From my point of view, at least the size and the domain sound useful information to have a quick view of recently downloaded files. We moved from a case where we were showing to much, to a point where we don't show enough to even distinguish entries.

I'm confirming this, then If we decide it's not worth we can still wontfix, but imo we really need to come up with a decision in case we'd be in time for a safe uplift in 55.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1

Comment 17

2 years ago
In my opinion the previous behavior should be back as it made things much more easy to use and did not clutter the panel at all.
With this new behavior I frequently have to open the download panel to check files, which is far from being comfortable as it was previously.

At least being able to see Size and Domain would be more helpful and more beneficial to productivity than without.

Comment 18

2 years ago
Why would you remove this in the first place?
I don't understand you people.

Comment 19

2 years ago
The old way of showing download panel should be definitely bring back. New is super confusing. Too many clicks to get to crucial information  about downloaded file. Why you devs brought this changes? What for? Dear Devs, we like to know what's going on on our computers.
Bring back the old way of showing download panel...
(In reply to :Paolo Amadini from comment #13)
> ...but we still need a decision from Bryant.

Sorry for the late reply, I was at a conference last week. If people find it hard to discover the information (file size, domain, date) in hover state and compare the information among different files, that means the design might have usability flaw and need to be fixed. 

My proposal is to bring the file size up front so people can identify different files even if they share the same name. But I still concerning if it's necessary to uplift the domain name and date from the hover state. I think in general use case, user care more about what's the file and how the download progress. Anyway, I'll discuss the issue with Sean and Morpheus, and see if we can come up a better solution for that.
Flags: needinfo?(bmao)

Comment 22

2 years ago
(In reply to Bryant Mao [:bryantmao] from comment #21)
> (In reply to :Paolo Amadini from comment #13)
> > ...but we still need a decision from Bryant.
> 
> Sorry for the late reply, I was at a conference last week. If people find it
> hard to discover the information (file size, domain, date) in hover state
> and compare the information among different files, that means the design
> might have usability flaw and need to be fixed. 
> 
> My proposal is to bring the file size up front so people can identify
> different files even if they share the same name. But I still concerning if
> it's necessary to uplift the domain name and date from the hover state. I
> think in general use case, user care more about what's the file and how the
> download progress. Anyway, I'll discuss the issue with Sean and Morpheus,
> and see if we can come up a better solution for that.

It's crucial information form where file is downloaded and when. If there is few files with the same name it is hard to see which is which. Also there can be  danger situation when link to file is changed by some malware software. In that situation there is no chance to stop download because  download bar will not show from where file is downloading. It is better to have more information than too few.
(In reply to Bryant Mao [:bryantmao] from comment #21)
> (In reply to :Paolo Amadini from comment #13)
> > ...but we still need a decision from Bryant.
> 
> Sorry for the late reply, I was at a conference last week. If people find it
> hard to discover the information (file size, domain, date) in hover state
> and compare the information among different files, that means the design
> might have usability flaw and need to be fixed. 
> 
> My proposal is to bring the file size up front so people can identify
> different files even if they share the same name. But I still concerning if
> it's necessary to uplift the domain name and date from the hover state. I
> think in general use case, user care more about what's the file and how the
> download progress. Anyway, I'll discuss the issue with Sean and Morpheus,
> and see if we can come up a better solution for that.

To correct the proposal, we think it is okay to add the file size/ domain /date(time) in the hover state and keep download status(Completed/Canceled/Fail) in the normal state. 

In general use case, people can easily monitor the download status by skimming through the panel. For the use case when people need the file size to differentiate multiple downloads that share the same name, or need to check the domain name to ensure if there are security issues, they could simply hover on the item and get the extra information they need.   

Paolo, let me know how you think about it.
Flags: needinfo?(paolo.mozmail)
(Assignee)

Comment 24

2 years ago
Sounds good to me. Thanks for looking into this.
Flags: needinfo?(paolo.mozmail)
(Assignee)

Comment 25

2 years ago
To clarify though, is this replacing the "Open File" message?
Flags: needinfo?(bmao)

Comment 26

2 years ago
I didn't get it, what's the downside of just simply reverting it to previous state, i.e. shows everything in normal state? It seems to me you guys consist on hiding those information (in hover state or whatever), is this the consensus among Mozilla employees? Because considering *all* the normal users appeared here seem to oppose it.

Comment 27

2 years ago
(In reply to Bryant Mao [:bryantmao] from comment #23)
> (In reply to Bryant Mao [:bryantmao] from comment #21)
> > (In reply to :Paolo Amadini from comment #13)
> > > ...but we still need a decision from Bryant.
> > 
> > Sorry for the late reply, I was at a conference last week. If people find it
> > hard to discover the information (file size, domain, date) in hover state
> > and compare the information among different files, that means the design
> > might have usability flaw and need to be fixed. 
> > 
> > My proposal is to bring the file size up front so people can identify
> > different files even if they share the same name. But I still concerning if
> > it's necessary to uplift the domain name and date from the hover state. I
> > think in general use case, user care more about what's the file and how the
> > download progress. Anyway, I'll discuss the issue with Sean and Morpheus,
> > and see if we can come up a better solution for that.
> 
> To correct the proposal, we think it is okay to add the file size/ domain
> /date(time) in the hover state and keep download
> status(Completed/Canceled/Fail) in the normal state. 
> 
> In general use case, people can easily monitor the download status by
> skimming through the panel. For the use case when people need the file size
> to differentiate multiple downloads that share the same name, or need to
> check the domain name to ensure if there are security issues, they could
> simply hover on the item and get the extra information they need.   
> 
> Paolo, let me know how you think about it.

Don't push it in hover state. Leave all information on the fornt. Sometimes, when file size is small, it's to little time to go  with cursor over list. This is VERY IMPORTANT form security reasons to see all informations on front.
(In reply to :Paolo Amadini from comment #25)
> To clarify though, is this replacing the "Open File" message?

yes, exactly.
Flags: needinfo?(bmao)
(In reply to fireattack from comment #26)
> I didn't get it, what's the downside of just simply reverting it to previous
> state, i.e. shows everything in normal state? It seems to me you guys
> consist on hiding those information (in hover state or whatever), is this
> the consensus among Mozilla employees? Because considering *all* the normal
> users appeared here seem to oppose it.

The downside is if you put everything upfront, you can't really skimming through it. We assume not all information are equal in the download context, so we prioritize the information in different states. I have to admit there are lots of tradeoffs when we are making those design decisions, and we definitely need more evidence to prove our assumption. But if we don't move and test, we'll never know what can be a better solution.

Comment 30

2 years ago
(In reply to Bryant Mao [:bryantmao] from comment #29)
> (In reply to fireattack from comment #26)
> > I didn't get it, what's the downside of just simply reverting it to previous
> > state, i.e. shows everything in normal state? It seems to me you guys
> > consist on hiding those information (in hover state or whatever), is this
> > the consensus among Mozilla employees? Because considering *all* the normal
> > users appeared here seem to oppose it.
> 
> The downside is if you put everything upfront, you can't really skimming
> through it. We assume not all information are equal in the download context,
> so we prioritize the information in different states. I have to admit there
> are lots of tradeoffs when we are making those design decisions, and we
> definitely need more evidence to prove our assumption. But if we don't move
> and test, we'll never know what can be a better solution.

That makes sense. Another idea is that maybe we can differentiate displayed information with things like font size, font color etc., to make the important ones (in this case, filename, I assume) more stand out for skimming without hiding others straightly.
(In reply to maxm from comment #27)
> (In reply to Bryant Mao [:bryantmao] from comment #23)
> > (In reply to Bryant Mao [:bryantmao] from comment #21)
> > > (In reply to :Paolo Amadini from comment #13)
> > > > ...but we still need a decision from Bryant.
> > > 
> > > Sorry for the late reply, I was at a conference last week. If people find it
> > > hard to discover the information (file size, domain, date) in hover state
> > > and compare the information among different files, that means the design
> > > might have usability flaw and need to be fixed. 
> > > 
> > > My proposal is to bring the file size up front so people can identify
> > > different files even if they share the same name. But I still concerning if
> > > it's necessary to uplift the domain name and date from the hover state. I
> > > think in general use case, user care more about what's the file and how the
> > > download progress. Anyway, I'll discuss the issue with Sean and Morpheus,
> > > and see if we can come up a better solution for that.
> > 
> > To correct the proposal, we think it is okay to add the file size/ domain
> > /date(time) in the hover state and keep download
> > status(Completed/Canceled/Fail) in the normal state. 
> > 
> > In general use case, people can easily monitor the download status by
> > skimming through the panel. For the use case when people need the file size
> > to differentiate multiple downloads that share the same name, or need to
> > check the domain name to ensure if there are security issues, they could
> > simply hover on the item and get the extra information they need.   
> > 
> > Paolo, let me know how you think about it.
> 
> Don't push it in hover state. Leave all information on the fornt. Sometimes,
> when file size is small, it's to little time to go  with cursor over list.
> This is VERY IMPORTANT form security reasons to see all informations on
> front.

Can you tell me more about the "sometimes" situation? Like when and where it would usually happen? And how often the use case might occur based on your personal experience?
(Reporter)

Comment 32

2 years ago
Like when you download a file that you expect to be ~200Mo, and it was actually a 200Ko file,n like a downloader software of the thing you wanted to download. This occurs very often with some **** 1st-search-engine result websites, that say you'll get a file (ie: Open Office off line installer) while they actually serve you another one (often a bad/malware one). I see it on a regular basis for my non-tech friends. Removing the file size or hiding it makes it harder to teach them that "if file is too small, then it's a trap".

Another situation is when downloading a video, and having the server/connection shut down in the middle of that download. Sometimes (ie: when the server did not tell the browser the total file site), the shutdown did not result in a "failed file" in FF download manager. In such case, I bet not having the file size directly shown will lead to keep broken videos on your drive (and discover, days later when you'll actually play it, that it was not fully downloaded).

And last, I rarely see users (at work of friends) waiting few seconds hovering something to get extra infos. It seems to be not a so-widespread behavior. They either expect the info to be there right away, or just never try to hover the thing and never know the info was here (hovering every little thing to maybe expect a title bubble to maybe give you the info you're looking for seems not to be a very user-friendly UX design IMO).
Comment hidden (advocacy)
Just as a reminder, this is a technical ticketing system, please only report relevant technical information that has not been reported yet and that it would be useful for the bug resolution, otherwise I may have to restrict comments :(

Comment 35

2 years ago
> Can you tell me more about the "sometimes" situation? Like when and where it
> would usually happen? And how often the use case might occur based on your
> personal experience?

I could not take it better than Vincent MONIER in comment nr 32.

Comment 36

2 years ago
How do you hover a UI item using a touch device ?

Comment 37

2 years ago
(In reply to Franck (Wip) from comment #36)
> How do you hover a UI item using a touch device ?

you can't, this is more reason not to take away this feature.

I can't understand how devs are being like these, power users need all those info there. if you wish to turn it off at least leave an option for us to turn it back on, for those who need them. im sure its not that hard and you're giving us option for a browser we love over chrome.

please revert it back as this is crucial info that people downloading files on a daily/weekly basis will need. many examples have been shown, please simply revert it or give us an option to reverse it and not shove inefficient changes down our throat.  the old method DOES NOT have too much info, it was perfectly fine the way it is.
Touch device is a great argument and considering the use cases and requests mentioned above, we decided to add the file size back to the normal state. We agree the file size has its importance and shouldn't hide in whatever situation. So for the download completed item, the new normal state substring will be "Completed - xMB" and the substring for hover state will remain as "Open file".
(Assignee)

Updated

a year ago
Assignee: nobody → paolo.mozmail
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)
Comment on attachment 8887472 [details]
Bug 1354568 - Show the final file size in the Downloads Panel.

https://reviewboard.mozilla.org/r/158324/#review164132

Thanks for the re-evaluation and the civil discussion :)
Attachment #8887472 - Flags: review?(mak77) → review+

Comment 41

a year ago
Pushed by paolo.mozmail@amadzone.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ec55743c3ed4
Show the final file size in the Downloads Panel. r=mak

Comment 42

a year ago
(In reply to Bryant Mao [:bryantmao] from comment #38)
> Touch device is a great argument and considering the use cases and requests
> mentioned above, we decided to add the file size back to the normal state.
> We agree the file size has its importance and shouldn't hide in whatever
> situation. So for the download completed item, the new normal state
> substring will be "Completed - xMB" and the substring for hover state will
> remain as "Open file".

so when does the file size get implemented back into the UI? nightly version 57?
(Assignee)

Comment 43

a year ago
(In reply to atst from comment #42)
> so when does the file size get implemented back into the UI? nightly version 57?

This will be in Firefox 56 Nightly, but we can likely uplift it to Firefox 55 Beta in a few days.
https://hg.mozilla.org/mozilla-central/rev/ec55743c3ed4
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 56
(Assignee)

Updated

a year ago
Flags: qe-verify+
(Assignee)

Comment 45

a year ago
Comment on attachment 8887472 [details]
Bug 1354568 - Show the final file size in the Downloads Panel.

Approval Request Comment
[Feature/Bug causing the regression]: Downloads Panel Redesign
[User impact if declined]: The final file size of a completed download would not be displayed in the Downloads Panel
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Not yet verified by QA, but tested in mozilla-central and this is probably enough to request uplift, given that the change in the code is really simple
[Needs manual test from QE? If yes, steps to reproduce]: Check that the final file size of a completed download is displayed in the Downloads Panel
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Low risk
[Why is the change risky/not risky?]: Really simple patch, and the change is limited to a very specific part of the feature
[String changes made/needed]: None
Attachment #8887472 - Flags: approval-mozilla-beta?
Comment on attachment 8887472 [details]
Bug 1354568 - Show the final file size in the Downloads Panel.

looks harmless enough, let's get this in 55.0b12
Attachment #8887472 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I have reproduced this bug with Nightly 55.0a1 (2017-04-07) on Ubuntu 16.04, 64 bit!

The fix is now verified on Latest Nightly and Latest Beta.

Latest Nightly:

Build ID 	20170725144053
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0

Latest Beta:
Build ID 	20170724125308
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
QA Whiteboard: [bugday-20170726]

Comment 49

a year ago
I have reproduced this bug with Nightly 55.0a1 (2017-04-07) on Windows 8.1 (64 bit).

The fix is now verified on Latest Nightly and Latest Beta.

Latest Nightly
Build ID   : 20170725030209
User Agent : Mozilla/5.0 (Windows NT 6.3; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0

Latest Beta
Build ID   : 20170724055319
User Agent : Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

[bugday-20170726]
As per Comment 48 and Comment 49, I am marking this bug as verified fixed.
Status: RESOLVED → VERIFIED
status-firefox55: fixed → verified
status-firefox56: fixed → verified
I have reproduced this issue using Firefox 52.0 (2017.03.02) on Win 8.1 x64.
I can confirm this issue is fixed, I verified using Firefox 55.0b12 and 56.0a1 on Win 8.1 x64, Ubuntu 14.04 x64 and Mac OS X 10.10.

Comment 52

a year ago
(In reply to :Paolo Amadini from comment #43)
> (In reply to atst from comment #42)
> > so when does the file size get implemented back into the UI? nightly version 57?
> 
> This will be in Firefox 56 Nightly, but we can likely uplift it to Firefox
> 55 Beta in a few days.

isnt 56 nightly already out few weeks ago? how can it be added if the version is already out?
(Assignee)

Comment 53

a year ago
(In reply to atst from comment #52)
> isnt 56 nightly already out few weeks ago? how can it be added if the
> version is already out?

Nightly installations have a dedicated update channel that receives updates very frequently, even though the main version number only changes with the same frequency as Firefox. Every day you might be using a different build of the same version, and it will include all the bug fixes recently marked as resolved. Hope this helps :-)
You need to log in before you can comment on or make changes to this bug.