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-requ...@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.
