- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Apr 2010 02:07:37 -0700
- To: Darin Fisher <darin@chromium.org>
- Cc: Eric Uhrhane <ericu@google.com>, Robin Berjon <robin@berjon.com>, Michael Nordman <michaeln@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Apr 1, 2010 at 1:03 AM, Darin Fisher <darin@chromium.org> wrote: > On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane <ericu@google.com> wrote: >> >> On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon <robin@berjon.com> wrote: >> >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote: >> >>> The only way to get a FileWriter at the moment is from <input >> >>> type="saveas">. What is desired is a way to simulate the load of a resource >> >>> with Content-Disposition: attachment that would trigger the browser's >> >>> download manager. >> >> >> >> I don't think that <input type=saveas> is a good solution for this, for >> >> one it falls back to a text input control, which is less than ideal. I think >> >> that the File Writer should trigger downloads on an API call since that >> >> doesn't introduce security issues that aren't already there. I'll make a >> >> proposal for that. >> > >> > Why not simply allow FileWriters be instantiated using: >> > >> > x = new FileWriter; >> > >> > And then make every call to .write open up the save as dialog. >> >> You wouldn't want to prompt on every write; developers might want to >> append a chunk at a time. >> You could prompt on creation, if you didn't mind that being a synchronous >> call. >> >> The reason I made an html element be the way of getting a FileWriter >> was to make the normal usage pattern not involve modal dialogs popping >> up in front of the user unprompted. With an inpput control, they can >> choose when to interact with it, rather than having a speedbump shoved >> in front of them. > > > Please no more JS functions that block on modal dialogs! :-) > @sicking: It seems odd to vary the behavior of .append based on how the > FileWriter was created. Perhaps we should provide some other asynchronous > means of creating a FileWriter? I'm not suggesting any blocking JS functions. Calling FileWriter.write() is specified as an asynchronous function. This gives a great opportunity to display the save-as dialog and, if the user press 'cancel', fire an error event, otherwise start firing progress events. Relying on asynchronous fetching of the FileWriter to deal with the save-as dialog seems to have two problems: 1. The file type isn't known at this time, so the user won't know what he's saving. 2. This always seems to grant the web page the ability to write unlimited number of times and unlimited amount of data, to the given location. Today, for things like Content-Disposition, the user only grants the right to save a single, known, file once. This is enough to solve many use cases. / Jonas / Jonas
Received on Thursday, 1 April 2010 09:08:29 UTC