Open Bug 249338 Opened 17 years ago Updated 1 month ago
progressbar doesn't indicate upload progress
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 When uploading with Firefox 0.9 and Firefox 0.9.1 (both clean installs) the progressbar doesn't "grow". Here are some HTML snipets of several site where I encountered this problem. ----------------------------------------------------- <h1>Upload files</h1> <p><strong>The maximum upload size is 2M.</strong></p> <form enctype="multipart/form-data" action="/upload.php" method="post"> <table border="0"> <input type="hidden" name="files" value="1"> <tr><td align="right">File 1</td><td><input type="file" name="file1" size="35"></td></tr> <tr><td align="right">File 2</td><td><input type="file" name="file2" size="35"></td></tr> <tr><td align="right">File 3</td><td><input type="file" name="file3" size="35"></td></tr> <tr><td align="right">File 4</td><td><input type="file" name="file4" size="35"></td></tr> <tr><td> </td><td align="right"><input type="submit" value="Upload Files"></td></tr> </table></form> ----------------------------------------------------- <form name=form method='POST' enctype='multipart/form-data' action='/cgi-bin/transfertest/httpupload.cgi'> <table> <tr><Td>Kies een bestand om te uploaden: </td><td><input type=file name=upfile></td></tr> <tr><td colspan=2> </td></tr> <tr><td align=right><select name=product> <option value=none selected> kies uit lijst </option> <option value=starter>chello starter</option> <option value=entry>chello entry</option> <option value=light>chello light</option> <option value=classic>chello classic</option> <option value=plus>chello plus</option> </td><td> Selecteer hier uw chello product (verplicht)</td></tr> <tr><td align="right"><input type=text name=postcode size=6 value="XXXXXX"></td><td> Vul hier uw postcode in (verplicht)</td></tr> <tr><td colspan=2> </td></tr> <tr><td align=right><input type=submit value=Upload onClick='return verifyForm()'></td><td> het bestand naar deze server</td></tr> </table><BR><BR> <font size="0">Het bestand zal na het uitvoeren van de upload test automatisch van de server worden verwijderd.</font> </form> Reproducible: Always Steps to Reproduce: 1. go to a site where you can upload some file 2. start upload 3. Actual Results: everything works fine...except the progressbar doesn't show the progress of the upload. Expected Results: like previous versions and other browsers like IE the progressbar should (slowly) "grow" indicating progress of upload. I have only encountered this problem with sites that use the post method in combo with enctype multipart/form-data I didn't see or tested other upload methods/combo's. This problem is with Firefox 0.9 and 0.9.1 only. I used clean installs, clean profiles.
I can confirm the bug in Firefox 0.9.1, but I don't have a Mozilla in the office to compare. I'll later tonight (note to self: landfill #804). Note: the progressbar was implemented in bug 24197.
bug also confirmed on Mozilla 1.8a2 on Mac OS X 10.2.8 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040701
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2) > bug also confirmed on Mozilla 1.8a2 on Mac OS X 10.2.8 > > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040701 -> Browser
Component: General → Networking: HTTP
Product: Firefox → Browser
Version: unspecified → Trunk
bug also confirmed on Mozilla 1.7 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 and on Mozilla 1.8a1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520. Btw on Mozilla Firefox 0.8 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 the progressbar does work properly. So the bug is both in the trunk as well as in the AVIARY_1_0_20040515_BRANCH.
I have marked some changes between nsHttpTransaction.cpp in ff 0.8 and current branche. The + marked are current changes and the - marked are from the 0.8 branche. Alas I don't have enough know-how of c++ and mozilla code structure to patch this bug, but I bet one or more of my - marked lines should be added again.
*** Bug 257975 has been marked as a duplicate of this bug. ***
Assignee: firefox → darin
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta
also confirmed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Priority: -- → P2
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
also confirmed in User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
*** Bug 311428 has been marked as a duplicate of this bug. ***
Confirming with Firefox 220.127.116.11 (en-us) on Windows 2000. I would much like to see this fixed. Thanks.
Please review bugs 349717, 243468, 255014 as duplicates. (These are the obvious ones in a search for "upload progress".) Despite the various changes listed in the other reports, this issue seemingly remains unresolved for Firefox 2.0 in Microsoft Windows. This bug is confirmed in 18.104.22.168 (Windows 2000), but for 2.0 (XP) the only case considered so far is eBay and I do not know whether they use POST or something altogether more painful. eBay image upload progress is not indicated at all in Firefox 2.0 itself (but simply by eBay's little floating div), making it impossible to monitor progress or see if the upload has completely stalled. I would imagine that eBay is peforming multiple POSTs, one per image and thus the progress bar should respond, but this is tricky.
-> reassign to default owner
Assignee: darin.moz → nobody
Status: ASSIGNED → NEW
I'd like to echo a suggestion given in duplicate Bug 255014 - the progress indicator should reside near, and be linked to, the upload control. In the likely event that a form permits more than one file upload, it would be helpful to see which files (and how much of them) have been uploaded; individually.
The regression occurred between 20040410 and 20040412, which gives http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=mozilla%2F&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-04-10&maxdate=2004-04-12&cvsroot=%2Fcvsroot as regression window. Bug 240053 is more than probably the culprit.
Is this going to be fixed in fx3? There has been no activity in the last few months...
Gawd, the file upload interface is bad enough as it is... having no progress means that there is basically NO feedback at all during an upload. In this wonderful new "Web2.0" world, file upload should be a first class citizen but gets no attention for some reason. Surely a working progress bar is the least FF could do, like IE...
I've been able to track down the regression more precisely. The culprits are bug 240053 and bug 257308. The code change involved is http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/base/nsDocLoader.cpp&rev=3.296#981 and #982 (2004-04-10 13:03) and http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/base/nsDocLoader.cpp&rev=3.296#984 to #997 (2004-09-17 13:33) Darin, do you have any idea about why these broke upload progress, after the years ?
No longer blocks: 255014
Maybe we should just implement a *proper* upload progress bar? With an actual percentage displayed, upload speed, and most importantly: estimated time left?...
(In reply to comment #22) > Maybe we should just implement a *proper* upload progress bar? With an actual > percentage displayed, upload speed, and most importantly: estimated time > left?... Why not. After all, upload progress bar is often more reliable than download progress bar (I'm not talking about download manager). But perhaps in a new bug. Anyway, if/once this bug gets fixed, extensions will be able to improve the upload progress bar in many ways.
> But perhaps in a new bug. Uhm, hello? I just filed Bug 437880 for that and it got marked as a duplicate of this.
Tim: Please vote for Bug 243468 which is for an IMPROVED upload progress display. That's a big job - but just fixing the existing progress bar (this bug) is probably not so big, and would be better than nothing.
Just a suggestion. How about the downloads window be renamed to "Transfers" and show there the file being uploaded and it's progress/status?
Confirming bug exists in Firefox 3.0.1. I can observe it while uploading a large file to the Google Code website.
Bug still exists in Firefox 3.6.3 - 6 years have passed by :) I am against showing the progress in a "transfers" or whatever window. The best place is the status bar. If would be nice to not only have a progress bar, but also some info about size, speed, time, filename...
Google Chrome implements this feature in the status bar : there is just a percent of the progress ("Transfer in progress (58%)"). There is no speeed, but you can estimate how long the uplaod will take , and you know if the upload is in progress or bugged. It could be a solution, at least for closing this bug.
is this going to block firefox 4 release?
UP!! Please implement it on firefox 4. Status bar need to show at least the percentage of upload progress, like chrome does. (In reply to comment #35) > Created attachment 452585 [details] > Screenshot of Chrome progress upload > > Google Chrome implements this feature in the status bar : there is just a > percent of the progress ("Transfer in progress (58%)"). > > There is no speeed, but you can estimate how long the uplaod will take , and > you know if the upload is in progress or bugged. > > It could be a solution, at least for closing this bug.
This is the fourth generation of Firefox and this little thing hasn't been fixed yet. Please fix it since this bugs a lot of people (source - various blogs).
We're no longer displaying the progress bar in the Firefox UI. I'm not sure what the UX team's plans are for this feature...
Just like chrome does
Dear developers, is it possible to reopen this case to implement this feature into firefox, the best browser in the world? the 3rd party addons are not reliable...pity...
I second that :) Just like our Download Button (UX Builds) We can show an Upward arrow , which would appear only while uploading and would disappear. This wont affect minimalistic design as well as will be informative and efficient.
To my previous comment, i made a quick mockup. I also reversed the direction of progress meter (which i dont know why , maybe making it feel as if we are sending it to the web?)
(In reply to Fabri from comment #44) > is it possible to reopen this case to implement this feature into firefox, This was never closed, AFAICS. You should instead hope that this feature gets implemented in SeaMonkey. The page-load progress bar is still there in that browser, so it is the path of least resistance. [sorry for the bugspam]
(In reply to bogas04 from comment #45) > Just like our Download Button (UX Builds) We can show an Upward arrow , > which would appear only while uploading and would disappear. The key difference between downloads and uploads is that the former are global, while the latter are tied to a specific tab, and are canceled automatically if the tab is closed. A global upload indicator that looks like the one for downloads could create confusion, leading people to think that the tab from which they started the upload can be closed. I think that, for large uploads, a progress indication is needed, even better if the estimated time remaining is shown. It should be tied to the tab, and ideally visible when switching to other tabs. I'm not sure what the current thinking of the UX team is on this issue, maybe the dev.usability forum can be a good place to discuss this in the context of the overall user interface direction.
In fact i think the best is to tie the upload indicator to the floating status bar, the one that from firefox 4 is on bottom left and indicate the links and the charging status of a page...
(In reply to Fabri from comment #49) > In fact i think the best is to tie the upload indicator to the floating > status bar, the one that from firefox 4 is on bottom left and indicate the > links and the charging status of a page... Looks good to me :-)
... and even better if we could also show the current progress in a place that is visible when switching to other tabs. But I'm not a UX specialist :-)
(In reply to Fabri from comment #49) > In fact i think the best is to tie the upload indicator to the floating > status bar, the one that from firefox 4 is on bottom left and indicate the > links and the charging status of a page... Like this ? http://s1.postimage.org/6qab7el44/Untitled.png
this is wonderful!
(In reply to Fabri from comment #53) > this is wonderful! Thank you :) :P mspaint FTW!!! Now lets wait for UX Devs to reply ...
Wait a second thats how chrome handles uploading status. So is this a parity Chrome now?
that's true actually...but when something works and it's good, why not to implement it only because it's in chrome...
getting a patch in that adds the percentage to the link hover area is fine for now (parity). Some of the longer term ideas we had were: -progress bars at the top of the tab that showed both loading and uploading progress (so you could switch to another tab and still monitor when the upload is complete) -exposing the upload progress with the default file picker using a progress bar below the path text field -making it easy for web sites to provide their own in content UI for upload feedback (it's my understanding that a lot of sites use flash for this right now?)
Are there any plans to fix this bug?
Any news on that (as it looks) simple matter?
Firefox nightly 27.0a1 lost progress bar
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Can you give some explanation why you're closing this bug as "won't fix"? It really doesn't make sense to me why user agents don't display upload progress by default. I do know Upload Progress, but as the developer of a simple file-sharing site (private and for collaboration purposes) I also know how often I need to explain to my users that it should not be the server's task to inform users about the progress of an upload. It's so much more natural for the user agent to do this.
as comment 60 says, we've done away with the progress bar even for downloads..
there are sufficient transporteventsink events to do this with an addon fwiw..
May I remind you that this is not filed against Firefox, and there are other Mozilla browsers that still have a progress bar? (SeaMonkey)
Patrick, Core ≠ Firefox. If this is now purely a UI issue and Firefox developers don't want to implement it, please reopen the bug and reassign it from Core to SeaMonkey.
Response to comment 63: Add-ons are not the answer I’m looking for. There already is one that does the job nicely and I mentioned it in my comment 61 – Upload Progress. I should not have assumed people know it. The issue is that people tend to contact me when they’re in the middle of a long upload, and that’s not a good time to tell them to install an add-on. Regarding comment 62, I didn’t know the less in comment 60 is deliberate. I also think it’s a mistake. But even so, it’s still possible to view download progress by opening Tools → Downloads, perhaps an indicator for upload progress should be added there then.
Sorry: change "less" to "loss" in my previous comment.
(In reply to Tristan Miller from comment #65) > Patrick, Core ≠ Firefox. Core platform decisions do not consider seamonkey or thunderbird. not my decision - but I'm not going to shy away from it. Happy to recategorize the bug as seamonkey though.
Status: RESOLVED → REOPENED
Component: Networking: HTTP → UI Design
Product: Core → SeaMonkey
Resolution: WONTFIX → ---
Target Milestone: mozilla1.9alpha1 → ---
Well, I see that the issue reported here doesn’t really exist in Firefox anymore. But I do think Firefox should by default have some way of indicating upload progress. (I have nothing against the add-on of the same I mentioned before other than the fact that it should not be necessary to install it.) If this bug is going to be recategorised, can I enter this as a new bug? Would the new bug be considered?
I guess you could open a firefox (not core) ui bug - it might get wontfixed tho.
Okay, I have now submitted bug 1240781. Please treat it with compassion. :-)
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
You need to log in before you can comment on or make changes to this bug.