W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: The most basic File API use case

From: Peter O. Ussuri <ussuri@threetags.com>
Date: Thu, 10 Dec 2009 13:23:44 -0500
Message-ID: <65dfc9010912101023m2815b998iad91edd9fcd1f9ba@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Robin Berjon <robin@berjon.com>, public-webapps WG <public-webapps@w3.org>
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.

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.

Received on Thursday, 10 December 2009 18:24:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC