progressbar doesn't indicate upload progress

REOPENED
Unassigned

Status

SeaMonkey
UI Design
P3
normal
REOPENED
13 years ago
4 months ago

People

(Reporter: splinter, Unassigned)

Tracking

(Blocks: 1 bug, {regression, ux-userfeedback})

Trunk
regression, ux-userfeedback
Bug Flags:
blocking1.9.2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-chrome])

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
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>&nbsp;</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>&nbsp;</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>&nbsp;&nbsp;Selecteer hier uw chello product
(verplicht)</td></tr>
<tr><td align="right"><input type=text name=postcode size=6
value="XXXXXX"></td><td>&nbsp;&nbsp;Vul hier uw postcode in (verplicht)</td></tr>

<tr><td colspan=2>&nbsp;</td></tr>
<tr><td align=right><input type=submit value=Upload onClick='return
verifyForm()'></td><td>&nbsp;&nbsp;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.
(Reporter)

Updated

13 years ago
Flags: blocking-aviary1.0-

Updated

13 years ago
Flags: blocking-aviary1.0-

Comment 1

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

Comment 2

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

Comment 3

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

Comment 4

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





(Reporter)

Comment 5

13 years ago
Created attachment 152189 [details]
nsHttpTransaction.cpp

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.

Comment 6

13 years ago
*** Bug 257975 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 255014

Comment 7

13 years ago
-> me
Assignee: firefox → darin
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta

Updated

13 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 8

13 years ago
also confirmed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Updated

12 years ago
Priority: -- → P2
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
(Reporter)

Comment 9

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

Updated

12 years ago
Target Milestone: mozilla1.8beta2 → mozilla1.9alpha

Comment 10

12 years ago
*** Bug 311428 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Priority: P2 → P3
QA Contact: general → networking.http

Comment 11

11 years ago
Confirming with Firefox 1.5.0.4 (en-us) on Windows 2000. I would much like to see this fixed. Thanks.

Comment 12

11 years ago
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 1.5.0.8 (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.

Updated

10 years ago
Duplicate of this bug: 376319

Comment 14

10 years ago
-> reassign to default owner
Assignee: darin.moz → nobody
Status: ASSIGNED → NEW

Updated

10 years ago
Keywords: polish, regression

Updated

10 years ago
Duplicate of this bug: 255014

Comment 16

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

Comment 17

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

Comment 19

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

Updated

9 years ago
Duplicate of this bug: 437880

Comment 21

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

Comment 22

9 years ago
Maybe we should just implement a *proper* upload progress bar? With an actual percentage displayed, upload speed, and most importantly: estimated time left?...

Comment 23

9 years ago
(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.

Comment 24

9 years ago
> But perhaps in a new bug.

Uhm, hello? I just filed Bug 437880 for that and it got marked as a duplicate of this.

Comment 25

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

Updated

9 years ago
Duplicate of this bug: 442034

Comment 27

9 years ago
Just a suggestion.

How about the downloads window be renamed to "Transfers" and show there the file being uploaded and it's progress/status?

Comment 28

9 years ago
Confirming bug exists in Firefox 3.0.1.

I can observe it while uploading a large file to the Google Code website.

Updated

9 years ago
Duplicate of this bug: 451822

Updated

9 years ago
Duplicate of this bug: 452269

Updated

9 years ago
Duplicate of this bug: 465217

Updated

8 years ago
Flags: blocking1.9.2?

Updated

8 years ago
Blocks: 243468
Duplicate of this bug: 486647
Flags: blocking1.9.2? → blocking1.9.2-

Updated

7 years ago
Keywords: polish → ux-feedback

Updated

7 years ago
Duplicate of this bug: 573334
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...
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.

Comment 36

7 years ago
It's kind of dull that such a basic thing doesn't work while Mozilla spends Google money on Personas or faster javascript...

Comment 37

7 years ago
is this going to block firefox 4 release?

Comment 38

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

Updated

6 years ago
Duplicate of this bug: 631839

Comment 40

6 years ago
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).

Comment 41

6 years ago
I've made an add-on (pure javascript) that displays the upload progress with % and ETA. Is open source and I think it would be great to include it in FF kernel. I can help if you have doubts or suggestions, take a look: https://addons.mozilla.org/en-US/firefox/addon/uploadprogress/
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...

Comment 43

6 years ago
Just like chrome does

Comment 44

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

Comment 45

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

Comment 46

6 years ago
Created attachment 564847 [details]
Suggestion : Upload Button (Just like Download Button in UX Builds)

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?)

Comment 47

6 years ago
(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]

Comment 48

6 years ago
(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.

Comment 49

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

Comment 50

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

Comment 51

6 years ago
... 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 :-)

Comment 52

6 years ago
(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

Comment 53

6 years ago
this is wonderful!

Comment 54

6 years ago
(In reply to Fabri from comment #53)
> this is wonderful!

Thank you :) :P mspaint FTW!!! Now lets wait for UX Devs to reply ...

Comment 55

6 years ago
Wait a second thats how chrome handles uploading status. So is this a parity Chrome now?

Comment 56

6 years ago
that's true actually...but when something works and it's good, why not to implement it only because it's in chrome...

Updated

6 years ago
Whiteboard: [parity-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?)

Comment 58

5 years ago
Are there any plans to fix this bug?

Comment 59

4 years ago
Any news on that (as it looks) simple matter?

Comment 60

4 years ago
Firefox nightly 27.0a1 lost progress bar
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX

Comment 61

a year ago
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..

Comment 64

a year ago
May I remind you that this is not filed against Firefox, and there are other Mozilla browsers that still have a progress bar? (SeaMonkey)

Comment 65

a year ago
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.

Comment 66

a year ago
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.

Comment 67

a year ago
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 → ---

Comment 69

a year ago
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.

Comment 71

a year ago
Okay, I have now submitted bug 1240781. Please treat it with compassion. :-)
You need to log in before you can comment on or make changes to this bug.