Re: The most basic File API use case

On Thu, Dec 10, 2009 at 10:23 AM, Peter O. Ussuri <ussuri@threetags.com> wrote:
> On Wed, Dec 9, 2009 at 4:30 PM, Eric Uhrhane <ericu@google.com> wrote:
>
>> I lean toward an input
>> element that requires a user action to bring up the dialog box, but
>> I'm still thinking about it.
>
> Currently, a user action is needed to trigger the download/save as
> prompt, as most browsers will block (as part of their pop-up blocking
> mechanism) window.open calls from delayed JavaScript code. So
> technically "group 0" use cases are consistent with this requirement.
>
> However, I'm not sure how removing the user action requirement can be
> abused if, for example, the browser blocks simultaneous saveAs prompts
> from the same page and allows easy closing ("killing") the page while
> the saveAs dialog is visible.

Yes, UAs can clearly put in some limits to try to counter abuse,
although they'll invariably guess wrong at least some of the time.
However, I just think it's better to avoid modal prompts whenever
possible.  Users are more likely just to click whatever will make them
go away than to consider and understand the ramifications of what
they're doing.  In the case of a file-save dialog, this might lead to
files being saved in whatever the default directory is even when the
user doesn't have a reason to trust the site.  If the user actually
has to bring up the dialog box by clicking on a "Save" button, we've
got evidence that there's some actual motivation behind the user's
action.

This is a fuzzy issue; there's no perfect answer.  The HTML control
doesn't actually fix anything; the idea is just that I suspect it'll
make things somewhat better and somewhat nicer to use than letting
pages pop up dialogs themselves.

> Let's consider a web app that re-encodes a video file from encoding X
> to encoding Y. If the user action requirement is present, at the end
> of the encoding process the app should tell the user "we've finished
> working; click 'save' to save your file", while without the user
> action requirement the app will just pop up the saveAs dialog. Not a
> big deal, just a usability hiccup.
>
> In summary, if there are potential security/abuse issues, the saveAs
> dialog should be allowed only in response to a user action. If there
> are no security issues, then the requirement should probably be
> dropped, I think.
>
> Thanks,
> Peter
>

Received on Thursday, 10 December 2009 20:53:24 UTC