[whatwg] creating a new file via the File API
David Karger
karger at mit.edu
Sun Dec 18 22:17:47 PST 2011
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.
>>>>
>>>
>
More information about the whatwg
mailing list