75.94 KB, image/png
103.50 KB, image/png
86.89 KB, image/png
143 bytes, text/html
This is split off from bug 44464. This bug is ONLY for the UI. That means the file picker and the edit box w/ whatever buttons it my entail.
Since we're trying to make an upload widget to handle multiple files, i think it's time to change our assumptions and display approach. I'd like to talk to the mail ui people about this because they should be working on this for their attachments widgets. +-----Files to send -------[Large Icons |v]-+--------+ | +---\ +---\ | Add | | | .| \ Untitled.txt | O| \ Text.html | Delete | | | .+-| (remote name: | .+-| (remote name: | Rename | | | TXT| "readme.txt") | WWW| "index.html") | View | | | ...| (as: Ascii) | ===| (as: Unicode) | Change | | +----+ +----+ | v | +----------------------------------------------------+ +-----Files to send -------[Details View|v]----------+ | Name ^| Remote Name | Encoding | Size |^| +--------------+--------------+-----------+--------| | | Untitled.txt | readme.txt | Ascii | 145kb | | | Text.html | index.html | Unicode | 987b |x| +--------------------------------------------------| | | <Add> <Delete> <Rename> <View> <Change> |v| +----------------------------------------------------+ The current single file attachment widget in navigator looks like this: [ File name .... ] [Browse ...] The netscape 4 messenger widgets look like this: /---+-------------------------------------------------------------+ | [L|File1 |^| |[A/|File2 | | | [O|Third Attachment | | | | |v| \---+-------------------------------------------------------------+ There is a bit of whitespace under third attachment (but not under the tabs, and ascii art can't demo this). On w2k clicking this gets me a standard common dialog box from 9x <dialog widgets="context-help,close" sizeable="false" orient="vertical"> <title>Enter File to attach</title> <box orient="horizontal"> <listbox caption="Look in:" accesskey="i" id="directoryChooser"/> <box id="navbar"><button id="back"/><button id="parent"/><button id="newFolder"/> <menubutton id="viewStyle"><menupopup> <menuitem value="Large Icons"/><menuitem value="Small Icons"/><menuitem value="List"/><menuitem value="Details"/><menuitem value="Thumbnails"/> </menupopup></menubutton></box> </box> <fileviewer directory="directoryChooser" views="viewStyle" multiselect="true"/> <grid><gridcols><gridcol/><gridcol/><gridcol flex="1"/></gridcols><gridrow> <gridcell><caption="File name:" accesskey="n" id="cFilename"></gridcell> <gridcell><input label="cFilename"/></gridcell> <gridcell><button value="Open" accesskey="o" default="true"/></gridcell> </gridrow><gridrow> <gridcell><caption="Files of type:" accesskey="t" id="cFiletype"></gridcell> <gridcell><listbox label="cFiletype" rdfsrc="plugin-supported-types"/></gridcell> <gridcell><button value="Cancel" cancel="true"/></gridcell> </gridrow></grid> </dialog> +------------------------------------------------------------------------+ |Enter file to attach [?][x]| +------------------------------------------------------------------------+ | Look _in: [ |v] <= |^] |=% [ v] | |+----------------------------------------------------------------------+| || || || || || || || || || || || || |+----------------------------------------------------------------------+| |File _name: [ ] [[ _Open ]] | |Files of _type: [ All Files (*.*) |v] [[ Cancel ]] | +------------------------------------------------------------------------+ Thankfully, mozmail includes the sizing widget and the places panel, however, mozmail does not support multiple concurrent selections. If it did, mozmail would need to change the dialog title to hint this. more later
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
This feature would make Web apps which handle upload of multiple files (Webmail services, for example) much nicer to use, as it would dramatically reduce the time required to attach multiple files. However, any UI for it would make such applications, as they are *currently* implemented, hopelessly confusing and error-prone -- since their instructions and online help currently assume that the form element only allows upload of a single file, and trying to upload multiple files using Mozilla's UI (rather than the app's) would usually cause the server to barf. Certainly this is a chicken-and-egg problem, but first we need a big enough chicken to be able to get away with it, and we need some eggs which are willing to be laid. The chicken is Mozilla's market share; Mozilla is too confusing as it is, and (unfortunately) I really don't think we can get away with something like this until Mozilla-based browsers have a market share of 30 percent or greater, such that they can't be ignored. The eggs are, for the most part, Webmail providers. We need to get a few of the big ones interested in deferring to Mozilla's multi-file upload UI, rather than providing their own, if the user is a sufficiently advanced version of Mozilla. mail.com, Netscape Mail, and Yahoo Mail would be a good start (and I suppose it wouldn't hurt to approach Hotmail as well). They would be gaining usability and bandwidth, at the expense of having to do a bit of browser-sniffing. Once the above two criteria are close to being met, *then* I can worry about exactly what this is going to look like. :-) Until then, Future. [jglick and sspitzer feel free to un-CC yourselves if you like, as this bug has exactly nothing to do with Mozilla mail/news, and I fear a flamewar.]
Status: NEW → ASSIGNED
Summary: UI for MultiFile upload dialog. → UI for <input type="file"> allowing multiple files to be uploaded
Whiteboard: high risk of confusion, require ~30 % market share
Target Milestone: --- → Future
This doesn't require lots of marketshare, it just requires inventing our own attribute (for example, <input type="file" multiple>), as suggested in bug 44464 comment 72. Browsers that don't know what "multiple" means will just treat the control as a single-file upload control. The HTML author would be responsible for making the layout not break when the size of the control changes, which isn't hard and should be done anyway to allow for text zoom != 100%. The CGI would be responsible for handling multiple files. In fact, I think that waiting for lots of marketshare before adding support for <input type="file" multiple> is a bad idea. /Sites/ might want to wait until 10% of their users have browsers suporting <input type="file" multiple>, but that will happen most quickly if Mozilla adds support now. Adding this feature without requiring a "multiple" attribute would also be a bad idea. Many CGIs are not designed to handle multiple files, either because the programmers didn't know that multiple files were possible, or because they didn't have any implimentations to test against and so didn't know the expected POST format for multiple files.
NO! DON'T INVENT A NON-STANDARD ATTRIBUTE! Mozilla prides itself as being standards compliant. Multiple-file upload is standard feature documented in the HTML 4 standard. I still think the best solution to the adding the feature remaining standards compliant, while not likely to break things ACCIDENTLY is the "stealth (legacy)" interface that the very first patch (with the backend patch) introduced... allow the file-selection dialog to allow for multiple selections and/or define a filename separator. This insures that the functionality is there but makes it unlikely that a user hits the feature unintentionally. By not changing the appearance of the file input control, it is least likely to create undesired/unexpected behavior with all the existing legacy pages. For new pages that actually use multiple file input, I suspect the pragmatic initial approach will be for the page itself to document how to do this ("you can submit multiple files... blah blah") until the behavior becomes common place.
Havill: your solution works until a user visits one site that says he can select multiple files, and then visits another site that doesn't say he can't. Then the user will get a confusing error message from the site, or wonder why only one file was attached to his mail message, or might even end up sending corrupted data. (I'm curious as to which is most common with today's servers and cgis.)
Opera already supports multiple-file-upload, but does it using a standard Open dbox in which one may simply select more than one file. This is not a good long-term solution as it makes it impossible to select files to upload from different directories (without typing in the field itself). Ways for a form to signal it understand and wants to receive MFU? - DOCTYPE switch? (too much overloading IMO, and may discourage people more from using Standards Mode) - enctype="multipart/form-data;multiple=yes" ? Would this break any current browsers? - input type="file" value="multiple" ? Dodgy but since 'value' as an attribute is now effectively unused...?
Assignee: mpt → jkeiser
Status: ASSIGNED → NEW
Component: User Interface Design → HTML Form Controls
QA Contact: zach → tpreston
I have to agree that it is strange to wait for market share on this one. As a vendor of a large-scale web application dealing with corporate document management, multiple file upload is obviously a huge feature for us and our clients. Currently, anyone who asks for multiple upload support has Opera recommended to them, simply because it does support multiple file uploads and there's nothing else out there that does. Build it, and not only will "they" come, but I will send them to you. This is a huge opportunity for evangelism, in my opinion.
13 years ago
Depends on: 373866
Now I think there is enough marketshare and most people is using flash or java applets just for that.
<input type="file" min="1" max="5" /> should be sufficient, no? See comment #10, above. This would be immensely useful for sites like photo printing sites where right now I have to pick and choose each image individually. It's easy to lose track of which files have been selected, and which ones haven't when dealing with a few dozen separate input fields.
Looks like webkit has it sort of implemented http://trac.webkit.org/changeset/37863 _maybe_ something similar could land there as well?
Assignee: john → nobody
QA Contact: tpreston → layout.form-controls
re comment 11, bradley, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Whiteboard: high risk of confusion, require ~30 % market share
Sorry for my English. The idea is to draw on <select> element, it takes no more space than the classic version of the <input type="file">.
Comment on attachment 364069 [details] Suggestion for <input type="file"> allowing multiple files so. "no". you need to be able to individually remove files that are added, and that would not be through a drop down, it'd probably be through a scrollable frame, perhaps w/ some sorting and drop target behavior. and it'd probably involve the user being able to pick destination filenames.
Attachment #364069 - Flags: ui-review-
(In reply to comment #17) > (From update of attachment 364069 [details]) > so. "no". > > you need to be able to individually remove files that are added, and that would > not be through a drop down, it'd probably be through a scrollable frame, I think it could be done through a dropdown too – the same way it's done with addresss bar suggestions in recent versions of MSIE.
ie's feature has been around for many years, virtually no one knows about it. now please, if you want to actually provide an implementation, ok. otherwise, i'd like to limit this bug to implementations or suggestions from recognized ui designers (mpt, beltzner, mconnor, some designate).
Even https://bugzilla.mozilla.org/attachment.cgi?id=364069 is a lot better than what Chrome or Opera provides, but I agree something like https://bugzilla.mozilla.org/attachment.cgi?id=371152 would be better. Faaborg, any comments?
I think everyone probably agrees that a standard dialog is the best way to go for file selection (external consistency, we don't have to develop the interface ourselves, etc). In terms of editing the set of files, why not just use the standard dialog for that as well, allowing the user to deselect some files, and then once again set the (updated) list of files to be uploaded.
But how to show the selected files in the UI (in the web page).
Safari has a tooltip on hover that shows the list of selected files which works out pretty well.
(In reply to comment #24) > Safari has a tooltip on hover that shows the list of selected files which works > out pretty well. how does that work well, when one uses browser without mouse?
We are somewhat limited in vertical space, since Web pages have expected browsers to show a text field, right? If that is the case, then I think a comma delimited list, or something like what we were considering for our tagging UI (and the current interface of Mail.app) would work well, perhaps with each unit picking up the correct file icon. One of the nice things about this UI is that it allows for individual deletion, allows for drag and drop, etc.
(disregard the autocomplete aspects of that last attachment since they aren't really relevant for this case, and note that the drag and drop support is now relevant)
Yes, of course -- show the # of files selected all the time in the file element to minimize space usage, and then allow a hover or whatever action shows an element title to add the additional information of exactly which files are selected.
(In reply to comment #26) > Created an attachment (id=384509) [details] > Email address / tagging / horizontal list text field UI > > We are somewhat limited in vertical space, since Web pages have expected > browsers to show a text field, right? If that is the case, then I think a > comma delimited list, or something like what we were considering for our > tagging UI (and the current interface of Mail.app) would work well, perhaps > with each unit picking up the correct file icon. One of the nice things about > this UI is that it allows for individual deletion, allows for drag and drop, > etc. I think we are also limited in horizontal space, and in your example, more than one file would hardly be visible. Drop-down list would fit more files, and the list itself wouldn't be limited neither vertically, not horizontally. See attachment 371152 [details]. I'm not a "recognized UI designer", but I still think that is better (or rather, simply more flexible).
faaborg: i don't think we're limited in vertical space. <input type=file multiple> is new. as long as we *start* with showing something that takes more space, and perhaps lets people style constraints, we can use more space and developers will design for that. also note that just because an inactive element may have a certain size, doesn't mean that the activated version of the same element will. <select>, <input type=file>, and probably <select multiple> and <select> on mobile. looking at <select multiple> as a baseline, select in mobile browsers will show something like: ( first, second, third v) or ( 10 items v) clicking pops out a widget that lets you manipulate the list. [Hindex,Ifavicon,Cstyle v] clicking on this could pop out a view which lets the users select, drop target, rename, add, ... -- again, something like comment 1. I can certainly paint a version of comment 1 if it's necessary. looking at <select multiple size=5>, and noting that authors do use size to control things, and noting that OWA and friends do try to show more than one file vertically, i think it's reasonable to support a vertical layout, and probably default to 5 or something.
adding uiwanted keyword to keep this on my radar. ><input type=file multiple> is new. as long as we *start* with showing something >that takes more space, and perhaps lets people style constraints, we can use >more space and developers will design for that. Good to know, what other browsers support this so far, and what sizes are they using? The pop-out controls for mobile sounds totally reasonable, although as an unrelated side question, which mobile devices are we considering that actually expose a file system? In the case of the desktop creating a UI that roughly maps to the platform's file system UI might be ideal, but it really depends on how much space we have to work with.
Here's a dead-simple testcase that uses the "multiple" keyword in a file upload control. It can be used to test the UI, in browsers that support this feature.
(In reply to comment #31) > Good to know, what other browsers support this so far, and what sizes are they > using? I've tested Chromium 188.8.131.52 and Safari 4.0.1, and they both support this, using a control that's one line in height. It looks identical to their normal file-selector, but it says e.g. "2 files" in place of the filename. (As mentioned in comment 24, it also has a tooltip that contains the list of currently-selected files.) (In reply to comment #30) > as long as we *start* with showing something > that takes more space, and perhaps lets people style constraints, we can use > more space and developers will design for that. Not necessarily -- depending on how this plays out, developers may design for WebKit's single-line control and end up with pages that look horrible in Gecko if we default to a multi-line control. (Or the reverse could occur -- they may design for Gecko and end up with pages that look horrible in WebKit.)
>Not necessarily -- depending on how this plays out, developers may design for >WebKit's single-line control and end up with pages that look horrible in Gecko >if we default to a multi-line control. (Or the reverse could occur -- they may >design for Gecko and end up with pages that look horrible in WebKit.) Yeah, this is what I was worried about as well, and also why I wish all the browser vendors would talk about UI at least a little bit when standards are forming.
Maemo has a file system. It doesn't want people to think about it as a hierarchical file system, but it still has one, in fact it has more than one (since it can in theory expose UPnP or perhaps other strange beasts). Windows Mobile and WinCE have a file system. I'm sure I don't want to know much about it. iirc WinCE directories don't have "." or ".." but are otherwise "normal". Symbian has a file system (including "c:" and "e:", and yes, you really don't want to think about that). Alex: could you try to design something which takes more space? Hopefully we could find someone to do a draft impl, i doubt people are using this so much that they couldn't adapt to a bigger region. from an accessibility perspective, i do not like the idea of having a tiny box for a list of files, it's just a pain. (note: this isn't quite the same thing as "true accessibility", you can always reflect a stupid design via accessibility APIs.) Please note that file managers have moved away from using small icons in general (even OS X lets you use a large icon view in the file picker). I'd much rather be able to see 64x64 file icons than 16x16 icons, and i shouldn't have to zoom in on the page to figure out if i have the right set of files to attach. I think we're still at the point where site authors could give feedback to the other vendors if our impl is better, but we probably have to work on this soon if we want to go that way. could someone (daniel?) find a list of real sites who actually use this feature?
(In reply to comment #36) > picker). I'd much rather be able to see 64x64 file icons than 16x16 icons, and I have only seen people who switch file view from icon to details view. Icons dont have any value when all the files in your folders are *.doc or *.xls Those are the only two file formats we use at work. Even the screenshots pictures are embedded in the *.doc with description. At home other than for bugzilla, I only need *.jpg And one common thing I see people doing is, once they switch to detail view, they also sort file in date modified descending order.
>Alex: could you try to design something which takes more space? Hopefully we >could find someone to do a draft impl, i doubt people are using this so much >that they couldn't adapt to a bigger region. Ok, I'll put a few mockups together. Since we are dealing with files, the most logical approach is to leverage external consistency with the OS file system. In some cases we might not know how (or want to) match it, so we also need a generic UI to fall back to.
comment 40 containing patch to fix this functionality cut was removed, please repost the link
(In reply to comment #36) > could someone (daniel?) find a list of real sites who actually use this > feature? Some global sites: - GMail (uses their own Flash applet for multi-file upload, falling back to HTML 4 input, if no Flash available) - Yahoo Mail (offer their own add-on for multi-file uploads, if you deny it, Flash applet is used [YUI Uploader, I think]) - Flickr (uses another Flash applet for multi-file upload) - Wordpress.com (uses SWFUpload) Some regional sites (from my native Poland): - Interia.pl Mail (my employee, big portal - uses SWFUpload, falling back to HTML input, using WebKit's implementation of <input type="file" multiple>, if possible) - WP.pl Mail (another big portal, using their own Flash applet) Elsewhere: - lots of sites using SWFUpload - lots of sites using jQuery Uploadify - lots of sites using YUI Uploader Using Flash is a real PITA for users with different incompatible Flash versions, broken proxies, poor network connections and for servers with mod_security etc. (google for "error 2038"). So, many sites are trying hard to use this feature today.
Implementation of this feature should go hand-in-hand with Bug 243468 if we want to eliminate the need to Flash\Silverlight uploaders altogether
This is off topic, but why would one need Flash/Silverlight for uploaders? Gecko supports <input type="file" multiple> and one can pretty easily create upload progress bars using File API, XMLHttpRequest and Progress events.
This bug deals with the UI of the text box and browse button _after_ the files have been selected. Right now all you see is a text box with maybe a file name and part of another one followed by the browse button. Not a very helpful UI to deal with the files to upload if you need to make any changes. And off topic as well, but a major problem than this UI which can be dealt with JS, is multiple file download, i.e. being able to select and download multiple files, or just download multiple files from a link (in sequence maybe). Resorting to a "here is a zip of all the files" is not always practical or convenient for the user.
(In reply to comment #42) > This is off topic, but why would one need Flash/Silverlight for uploaders? > Gecko supports <input type="file" multiple> and one can pretty easily > create upload progress bars using File API, XMLHttpRequest and Progress events. Because the input for browsing files cannot be customized, cannot change style, cannot change the english text "browse", in few words its very limited. Flash is used because of much more functionality. I dont see how Gecko supports mutiple file uploading when this bug is not fixed, even if there is some way, a cross-browser solution is needed and currently that is flash.
Do this bug has any priority?
(Note that this bug hasn't been touched in ~3 years) I think this might've been actually been FIXED in another bug. At least, my attached testcase (attachment 385886 [details]) works in Firefox nightly -- it matches the Chromium/Safari behavior I described in Comment 33 here. (allows you to select multiple files, and if you do, it'll say "2 files" instead of the filename, with a tooltip to give you the filenames) Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0
Support for <input type="multiple"> was added in bug 523771. More discoverable UI would be great.
(In reply to Jesse Ruderman from comment #47) > Support for <input type="multiple"> was added in bug 523771. More > discoverable UI would be great. We should probably close this ticket and open another one then?
Yes. When this bug was filed, we didn't implement <input type="multiple">. Now we do. If there are still issues with our implementation, please file new bugs.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.