- From: David Karger <karger@mit.edu>
- Date: Mon, 19 Dec 2011 01:17:47 -0500
When I run your example in chrome, all those links automatically download the file to the specified filename in my default download directory---none launch the file save dialog. Of course that's because of how my chrome defaults are set. And indeed I can right click and file-save-as. But it's going to be a problem if I want to put a "save as" button on the page---having that result in download to a default directory because that's how chrome defaults are set isn't going to be the right behavior from the user's perspective. Should there be a way to force open the save dialog, even if the default is to download to a fixed location? On 12/19/2011 12:35 AM, Bronislav Klu?ka wrote: > hi, > if you look at the generated files examples, what you can see there > (again, only in chrome) is that > 1/ I have some data in JS > 2/ I create blobbuilder -> blob -> url to that blob > 3/ I create a element with URL to that blob and download attribute > 4/ I initiate click on that link programmaticaly > > the result is is that Save file dialog is opened and when save/ok > button is hit, the blob data is stored in user selected file. > Yes, I'm using download attribute, but URL is JS blob (local data). > I do not see problem here. What are you missing? > > And yes, I also do not see security issues here, nothing user cannot > do today with regular download or programmer by uploading data to > server and then download them... > > B. > > > > > On 19.12.2011 6:26, David Karger wrote: >> Hi, >> >> What you're doing is certainly connected, but I don't think it >> solves the problem I outlined. Your approach allows specification of >> the download target as an attribute in html. That's useful, but >> what's still missing, and I consider important, is a way to connect >> the html document to the "Save As" dialog available on all OSes. >> <input> tags lead browsers to launch the "Open File" dialog, which >> lets the user naturally navigate their file system to select a file >> to open. Browsers also launch the analogous "Save As" dialog, but >> _only_ when you execute a download from a server. I think it's >> important to enter the same "Save As" dialog programmatically, for >> client-side generated content. I don't think this raises the >> security issues discussed at mozilla, because the user is engaged in >> the same interaction as they are on any other file download. >> >> >> On 12/18/2011 11:13 PM, Bronislav Klu?ka wrote: >>> Hi, >>> >>> This is quite crucial functionality and sadly not being addressed as >>> it would seem, because without it application cannot really be >>> applications (all you can do is to prepare data, upload those data >>> to server and let user download it manually by clicking somewhere, >>> which is annoying, unnecessary, and quite frankly stupid) . >>> >>> >>> but there is a way howto allow user to save file from javascript >>> without flash >>> >>> http://www.webnt.cz/demos/034_a_download/ >>> >>> this demo (the generated files) allows you to download/drag'ndrop >>> generated file using JS (no flash) >>> it's working in Chrome only at this point >>> FF team is having some security issues I've been discussing with them >>> https://bugzilla.mozilla.org/show_bug.cgi?id=676619 >>> >>> >>> >>> B. >>> >>> >>> On 16.12.2011 0:58, David Karger wrote: >>>> It isn't clear to me that a "tag" question can be addressed by an >>>> "api" answer. Even if there is an api for saving to file, isn't >>>> there value to being able to declare your intentions through a >>>> tag? The <input type=file> tag specifies that a user will be able >>>> to interact to specify a file through a dialog. There's absolutely >>>> no commitment that that file will actually be uploaded or input. >>>> That's up to the form or the javascript that handles the input. It >>>> seems entirely consistent to be able to permit specification of a >>>> brand new file in that dialog that <input type="file"> is already >>>> creating. What some javascript _does_ with the specified file >>>> might need to be implemented using a filesaver api, but that's >>>> separate from the declaration of an interaction for specifying the >>>> file. >>>> >>>> On 12/15/2011 6:45 PM, whatwg-request at lists.whatwg.org wrote: >>>> >>>> On Mon, 15 Aug 2011, David Karger wrote: >>>>> / >>>> />/ Apologies if I'm revisiting old territory. I've been doing >>>> work on pure >>>> />/ html/javascript applications that work entirely clientside >>>> />/ (http://projects.csail.mit.edu/exhibit/Dido). For >>>> persistence, they >>>> />/ read and write local files. There's already an<input >>>> type="file"> >>>> />/ interface for letting the user specify a file to be read. And >>>> I can use >>>> />/ the same interface, inappropriately, to let the user overwrite a >>>> />/ preexisting file. But things get much messier if I want to >>>> let the user >>>> />/ specify a _new_ file to be written, because the file-open >>>> dialog doesn't >>>> />/ offer users a way to specify a new filename. What I'd like to >>>> be able >>>> />/ to do is specify a tag, or a invoke some javascript method, >>>> that will >>>> />/ produce the "save file" dialog typical of most systems, with a >>>> graphical >>>> />/ directory browser but including the option to specify a new >>>> filename. >>>> />/ This problem isn't unique to me; a discussion on stackoverflow >>>> appears >>>> />/ at >>>> />/ >>>> http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file >>>> />/ where the proposed solution is to use flash---and that would >>>> be an >>>> />/ unfortunate loss of html5 purity. They also suggest the hack >>>> of using a >>>> />/ data: url but that has size limitations. >>>> />/ >>>> />/ Perhaps<input type="file"> could be given an attribute >>>> specifying >>>> />/ whether a new filename is permitted? >>>> / >>>> On Wed, 7 Sep 2011, Eric U wrote: >>>>> / >>>> />/ This sounds like a job for the FileSaver interface. Currently no >>>> />/ browser implements it, but we at Chrome have been considering >>>> it. At >>>> />/ TPAC last year we discussed it a bit in the WebApps WG >>>> meeting; IIRC we >>>> />/ talked about letting it take a URL instead of or in addition >>>> to just a >>>> />/ Blob, for more general utility. >>>> />/ >>>> />/ I suggest you bring it up on public-webapps@, where that spec >>>> lives. >>>> />/ >>>> http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver >>>> / >>>> I agree that an API like FileSaver is the right way to do this. Using >>>> <input type=file> wouldn't really fit well because that's more for >>>> providing data for upload than providing a file for writing. >>>> >>> >
Received on Sunday, 18 December 2011 22:17:47 UTC