Closed Bug 243468 Opened 20 years ago Closed 1 year ago

Improved form upload manager/progress display

Categories

(Toolkit :: Form Manager, enhancement)

enhancement

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox42 --- ?

People

(Reporter: mozilla.20.campbeln, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

It would be nice to have a "form upload progress bar/display" that contains
Bytes Transferred, Total Bytes, Speed, Est. Time Remaining, etc (something kinda
like the downloads interface I guess).
I encounter this problem when trying to upload large files to my web-based
email. More times then not, I'll return to the tab and forget what I was in the
middle of, figure the site stalled and hit reload. The status bar’s loading
progress bar simply isn't enough (and seems to be based more on time then data
transferred/total data).

Reproducible: Always
Steps to Reproduce:
The progressbar was implemented in bug 24197. Do you want a dialog box instead ?
For large files only ?
(In reply to comment #1)
> The progressbar was implemented in bug 24197. Do you want a dialog box instead ?
> For large files only ?

Just reading over bug 24197... this is basically the same/or a very similar
request. I don't believe I've seen the functionality implemented under bug
24197. And no, I'm not sure a new dialog would necessarily be the best solution.
The download dialog *sometimes* gets in my way as a user, but in general it is a
nice interface (certainly better then that “other” browser ;).

Basically I believe it would be nice to know how much data has been uploaded,
how much is left to upload and about how long it's going to take. Else as a
user, you run into the "barber pole"/"I think the browser has stalled" problems
described in bug 24197. 

Maybe adding this information to the current Download Dialog (essentially making
it a Transfers Dialog) would be a good idea?! Else having this or similar
information displayed in the status bar might work?
(In reply to comment #1)
> The progressbar was implemented in bug 24197. Do you want a dialog box instead ?
> For large files only ?

Almost forgot... any implemented interface should have a startup pause (like the
Download Dialog does). That is, any upload transfer information should wait 'x'
seconds before displaying, so that any small uploads/form submissions are not
encumbered by any additional interface. So not necessarily an interface just for
large files, but for uploads that take more then 'x' seconds to complete.
How about adding this info to the status bar? Kinda like bug 88982.
(In reply to comment #4)
> How about adding this info to the status bar? Kinda like bug 88982.

Yea, but I still think the best location for it would be within the current
"download" dialog (making it a "transfers" dialog). I don't think the status bar
would/could be as verbose (and what happens when you go to another tab?), but
again, it would work.
Assignee: general → guifeatures
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: GUI Features
Ever confirmed: true
QA Contact: general
Summary: Feature Request: Get/Post Form Upload Progress → Get/Post Form Upload Progress in a dialog
*** Bug 253105 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
I don't think mixing uploads in with downloads is a good idea, since the uploads
are generally treated differently:

They're not retryable (without re-submitting the form)
They can sometimes be grouped by multiple files (when a form has more than one
upload field)

Grouping the two will force the user to distinguish them from one another.
(In reply to comment #7)
> I don't think mixing uploads in with downloads is a good idea

I definitely see your point on this one, but I believe that creating a second
interface for Uploads is an even worse path to take. "Uploads" would look
visually simular to "Downloads", hence adding to user confusion. Not to mention
the addition of yet another interface and yet another open window. Maybe tabs
could be added to a unified "Transfers" interface, one for "Uploads" and one for
"Downloads"? (and maybe one for both?)

> They're not retryable (without re-submitting the form)

So why not have the option to resubmit the form? If the user closes the window,
the upload drops off the list. Else if the original window has been closed and
the user clicks “Resubmit”, a new tab is opened.

> They can sometimes be grouped by multiple files (when a form has more than one
> upload field)

True, and this fact does make "Uploads" programmatically different from
downloads. But again, why not have a link to "Resubmit the form" in place of
"Retry"? The user is trying to do a single upload transaction, which is
programmatically different from a single file download, but is still a single
unit of work.

> Grouping the two will force the user to distinguish them from one another.

Again, true but this could be done with a tabbed interface, differentiation of
colors/logos, etc. Again, I think adding yet another interface is a further step
in the wrong direction but you are right that user Upload -vs- Download
confusion has to be a major consideration in the design/redesign of the interface.
Nick, re-submitting the form is never a good idea because you can never fully
predict all the side effects, much less make the user aware of them. The last
thing you need is for the user to be responsible for (and I'm just thinking of
an extreme example here) duplicate charges for printing of a photo they uploaded.

Removing uploads when the form window is closed is yet another way in which they
will be different from other file transfers in the list.

The thing is that these HTTP uploads are part of a form submission, which will
result in a page being rendered in a particular window. Most users are more or
less aware of this. Therefore, they will periodically check up on the window in
question to see if the files are done uploading or not.

Therefore, I believe that giving the information about the status of a file
upload in the statusbar of a window is actually not that bad an idea. A simple
string like [Sending data: 43% (430Kb of 1Mb)... ETA: 2 minutes] will do the job
quite nicely. It can also provide a nice "hook" for extention authors to modify
this functionality (for example by adding a search-bar-like progress bar which
would be more explicit).
Hm, not much activity here.

I think the lack of visible progress for uploads is a real usability problem. The tiny progress bar (which might not be working at the moment...) is not enough for such an important operating as uploading a file, and doesn't give you any idea of the estimated time or how much actual data has been or will be transferred.

My suggestion would be a small non-modal frame of some kind that appears in the centre of the window, or perhaps right over top of the file browser controls in question, and shows all the usual progress details. 
Indeed, upload progress has been broken for 4 years: see bug 249338 

lev said:
"which will result in a page being rendered in a particular window. Most users are more or less aware of this."

I doubt this. Power/technical users are, but average users without vigorous prompting will assume that the web page is broken and either give up or click back and start again. Eventually, they may learn through painful experience.

Even power users can easily forget that a page which is apparently stalled is actually uploading; there is not much to remind you of it. 

Would anyone be happy if file downloads had no feedback other than the tiny throbber animation? If not then why should upload be any different?
This is essentially a dupe of bug 97412 "upload manager" ... logged in 2001.

I suggest we dupe and transfer our votes there ... comments?
After reading bug 97412 I can agree that this is essentially a dup and would be best suited to be integrated that way. The only caveat I have to this is to integrate the discussion from above therein (as there's been some nice to'ing and fro'ing regarding the implementation that I think is useful).

Is there any forward progress on this feature request? As you can see above there has been some debate both pro and con. Are we gonna get upload progress anytime soon?

Thanks all, I'll miss the email updates!
Actually, there is more discussion here than in bug 97412. I think it might be better to 
1. dupe 97412 to this one *
2. change the title on this one to "Form upload manager and progress" or similar.

* According to 
http://www.mozilla.org/quality/help/screening-duplicates.html
"all things being equal, newer bugs should be made DUPLICATES of older bugs"
but also 
"the bug reports that have less detail and work should be made duplicate of the bug reports that are further along"

So given that the discussion here is useful, I think thats the right way to go. Comments?



Thoughts?
I'm happy with that (I'll still get my reaffirmation from the emails =) and I agree that this discussion is more verbose. Is there anything you need me to do, admin. of bugs wise to accomplish this (title change, etc)?
Summary: Get/Post Form Upload Progress in a dialog → Form upload manager/progress dialog
Some comments from bug 97412:

xyzzy@dataphile.org > Sometimes uploads take a long time too, and the limited feedback may make the user want to abort the transfer.  A similar UI to the download manager could be adopted, or this could potentially be integrated into it....

Craig Nicol > ... it would allow me to cancel uploads if the upload is slow, with the intention of retrying the upload again at a later date...
Hrm, this should be both for Firefox AND the suite.
But, I'm guessing we should do Firefox first. Yes?
I agree that combining this with the download dialog would be too confusing and too much UI.

I agree with Aaron Lawrence that a tidy progress bar and upload info (transfer rate, % transfered, etc.) could be placed right where the file picker widget is on the screen.

If multiple files are being uploaded then the progress of each file would be conveyed on top of the associated file picker (if possible). If you canceled before completion then progress bars would go away leaving the file picker widgets.

As a web developer I have spent a decent amount of time implementing file upload progress bars via various method (polling the server, client side technologies such as flash, etc.). It would be nice if the browser supported this natively.
Changing to Firefox as first priority...
Assignee: guifeatures → nobody
Component: XP Apps: GUI Features → Form Manager
Product: Mozilla Application Suite → Firefox
QA Contact: form.manager
Sorry for the spam ... changing platform and OS to all
OS: Windows 2000 → All
Hardware: PC → All
I quite strongly disagree with the idea of making it a "dialog", or any other kind of separate window. That would be confusing to most non-technical users and probably cause navigability problems even for experienced users.

Personally I think it should be a toolbar on the bottom, similar to the QuickFind toolbar. It should contain all the information (transfer speed, ETA, etc.) and a cancel button as the only operable UI element (it's redundant because there's already a "standard" cancel button, but it's better to have it nonetheless because it is very relevant to the information displayed).

This toolbar would disappear when you switch to another tab and reappear when you switch back (if the transfer is still ongoing).
Yes a separate dialog seems like a bad idea, seeing as it is directly related to the page. I've taken the word dialog out of the description.

Some kind of panel toolbar on the page itself. 

However, it's important to note that it should be quite visible, not buried in a small area out of normal line of sight. After all you specifically DO NOT want people interacting with the web page while the upload continues.

Something like greying out the content and showing progress details in a frame in the centre of the page.
Summary: Form upload manager/progress dialog → Improved form upload manager/progress display
Now that it's no longer possible to type into the file upload "text box", it seems like the obvious place for a progress meter because it's rectangular.

[   3MB of 10.4MB (30%)   ] [Upload File]

You could change the background color like Safari does to implement a progress bar.

Of course, this doesn't help if a new page loads, but isn't there a way to trigger form submission without doing that?

Gerv
Yes, it makes some sense, however;
1) where would you indicate overall progress for multiple files
2) I don't imagine there is space to display all the information you would want, such as current speed.

Of course we now also have the issue of all the hacks that people have implemented to get around the lack of upload feedback - iframes and javascript submissions ... 
Product: Firefox → Toolkit
Here's a concept I had for the layout of an upload progress bar. The idea here is to keep it simple and unobtrusive while providing some useful information to the user. Some notes on this concept:
- There is only ever one (1) upload progress for each tab
- Would be on a timer as someone had mentioned before so that it's only seen for larger uploads
- The cancel button on the bar is just a shortcut to the browser "Stop" button but with a confirmation prompt
- Multi-file uploads are combined into this as a "Summary" progress bar.
- It's anchored to the bottom left of the viewport above the status bar
Looks really nice, but I do feel it should be more visible/noticeable, because it is is so important that users don't interrupt it.

Heres my conception. The whole page is greyed out and a frame is shown in the middle.
#27:
I can't say I disagree, but as a previous poster said we have to consider the "workarounds" that have been employed (ajax or otherwise) to sidestep/alleviate this issue up til now. A screen level graying could interfere with these workarounds. I like the suggestion in #26, but I agree with your concerns as well. Anyone have a solution that fits both (my ideas are well detailed in the previous comments)?

#26:
Agree and like the idea, as long as the "summary" includes the number of files as well as KB size (else it could be confusing to the user).
#27:
I would say this would be preferable for most sites. A small progress bar in the lower left corner is very easy to miss.

However, something would have to be done about the sites that use ajax workarounds. Would there be some way to detect if a site uses a workaround and not display this?
#27:
Looks nice, but if that is what gets chosen it poses a question: why don't all form submissions look like that?  If file upload form submissions cause the browser window to shroud like that then all form submissions should do it too.

#26:
I like this, but perhaps it should be at the top of the browser window and behave like the "password remember" prompt does (full width).
OK lets be a bit more specific. As I see it, all the information on #27 attachment is needed; besides the progress, it also needs to say how many MB are involved. I copied this data from the downloads manager. Theres no reason for it to be different as a lot of thought has already gone into the download manager.

Secondly, the little red X is usually a "close this panel" rather than a cancel. In this case I think it needs explicit text.

Perhaps in the future it wil not be necessary, but I also think its important to have some TEXT saying what is happening, reminding that files are being uploaded. Otherwise its easy enough to forget WHY it is taking so long.

So, I'm not especially attached to the greying out, but there needs to be more information than comment 26 suggests, and it needs to be more noticeable. 

Perhaps a larger dropdown panel from the top would be appropriate?
In firefox potentially important things dropdown from the top, not from the bottom.
I would like to bring up the issue of frames. It is theoretically possible to have more than one concurrent file upload in the same tab by having a framed website. Of course that would be a rather rare case; nonetheless, I think it would make sense to attach the upload progress bar to the frame rather than to the tab. The approach in Comment 26 is more suited for this.
Well that's a point. Still I think it should be at the top of the frame where it will be noticed, and larger to have all the necessary information. 

I would imagine that attaching any kind of toolbar/panel to a particular frame is probably difficult or impossible because it will be "inside" the (non secure) content.
It is common to use frames, or rather iframes, that have no width/height and submit forms into them.  This would really cause problems for that sort of interface, wouldn't it?

Any interface on a tab needs to be an aggregate of all its content, really.  That's the only way that makes sense.

It's true that for uploads, you shouldn't navigate away... but this problem (obviously one the browser should handle) has been around too long and too many other browsers lack the right features.  I would be wary of making Firefox too different from other browsers here, because it would only make things more of a problem for developers.

In other words, comment #27 is imho a horrible idea unless IE and Safari have the same thing.  Otherwise, it's going to be very difficult to make things clear across the board in documentation/etc.

Also, should note that many people were solving this problem using Flash to upload.  Flash Player 10 now has security features to prevent such a thing.

Personally, I would most prefer upload progress events to be exposed to JavaScript, and let the site handle it as it wants to (interface from comment 26, 27, or a better one for that site.)  Maybe a default implementation if the event was unhandled by JavaScript, but this allows everyone to have an interface that is perfect for their site.

-[Unknown]
"This would really cause problems for that sort of interface, wouldn't it?"
Which sort of interface? Greying out the page? I agree, forget that idea. Actually this would be better done with a reminder prompt 

"your files are still uploading, this will be stopped if you leave the page; are you sure you want to leave?"

A standard toolbar that appears at top or bottom, and is large enough to a) be noticed and b) contain all the useful information, as per download manager, will be fine.
Would these be a good feature to consider for blocking/wanted 1.9.2?  I'm not aware of any other browser that shows upload progress.  It would be a good opportunity for Firefox to be the first to get this nice extra bit of polish, especially if it's not too much work.  (I imagine that figuring out what interface is wanted would be harder than coding it.)
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Amusingly, Adobe has just recently broken most of the Flash upload applets in v10 by preventing programmers from doing the upload dialog programmatically.

Once again, I think a good upload UI should be part of the browser.
Depends on: 249338
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
This bug needs some love.

I agree with the proposal in comment 27. While uploading a tab should block until all uploads are complete, a transfer error occurs, or it's *explicitly* cancelled by the user. This means that Firefox should warn if the user tries to navigate to a different location.

It should not matter if there are multiple frames or some custom upload indicator. In the latter case the user will have two indicators, although the custom one might be hidden by Firefox's indicator.
Attached screenshot of how Chrome (5.0.307.9 beta Mac OS X) shows upload progress. This is the same be it one or five files. Just the percentage. That's already an improvement over the default behavior of FF.
I've been reading all the comments and I feel I should add my two cents:

1. Submitting a form should NEVER gray out the window or make it in any way unusable as shown in an attachment.
Youtube and lots of sites allow users to select a file, submit it and while it is uploaded, user can edit title, description and other things.

Disabling the whole website while something is uploaded is also bad from advertising point of view: some websites have ads and they say something like this "Feel free to visit our sponsors while your files are uploaded. Ads open in new windows by default". Graying out the whole window would change these classic behaviors. 

2. The panel/window/whatever should keep in mind that there may be multiple files uploaded. 

If user uploads several files on a poor connection and the server does something to uploaded files even if he loses connection, then he may be interested to know where the site timed out so that he doesn't upload the files again.

3. Dialog should be flexible enough to show the text and relevant information in other languages.

I'll upload an example of some kind of toolbar that should appear at the bottom of the page, or perhaps instead of the file dialog (granted it's a big high vertically)
Example of toolbar to show upload progress.
Maybe to use after submitting form instead of the file dialog (but what if there's more than one?) or pops up at bottom of the page after submitting form...

Designed in Visual Basic - ignore the window, consider just the client area (the gray stuff)
Well, this addon pretty much nails it.
https://addons.mozilla.org/en-US/firefox/addon/uploadprogress/

Now just roll this into FF and we're done.
I'm wondering as well, why this hasn't found it's way into Firefox, yet.

Just because there are ways to display the upload progress using js already? (xmlhttprequest)

I would really appreciate a UI for this

Now that the addon previously mentioned doesn't work anymore, this could be revisited. Chrome already supports it (and it always have done AFAIK), so it must be technically feasible. Also, it would be a little quality-of-life improvement for those who use and implement web services without JavaScript.

Severity: normal → S3

We aren't planning to implement this in foreseeable future.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.