[whatwg] creating a new file via the File API
Bronislav Klučka
Bronislav.Klucka at bauglir.com
Sun Dec 18 23:50:47 PST 2011
Hi,
yes, this is due to default browser behavior (my Chrome is set up to
always ask).
B.
On 19.12.2011 7:17, David Karger wrote:
> 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.
>>>>>
>>>>
>>
--
s pozdravem
Bronislav Klučka
http://www.bauglir.com <http://www.bauglir.com>
http://www.bauglir.com
Bronislav.Klucka at bauglir.com <mailto:Bronislav.Klucka at bauglir.com>
* webové aplikace
* software na zakázku
More information about the whatwg
mailing list