Re: Valid auto-invocation events

Bjoern Hoehrmann wrote:
> * Robin Berjon wrote:
>> in working on the Contacts API[0], DAP has described a security model in
>> which opening up a contacts picker (which is similar in idea to a file
>> picker, but — you guessed if — for contacts rather than files) can be
>> triggered only by code that traces back to a genuine user action. The
>> idea is that this would be similar to the way in which window.open() or
>> <input type=file>.click() are handled so as to prevent abuse but not
>> require an ugly control.
>
> And what is the problem you are trying to solve, exactly? Do you think
> there will be disputes where someone presents a plausible scenario and
> some people will say "this was a genuine user action meant to bring up
> the picker" and many others will plausibly claim it wasn't? UI design
> does not seem to allow for this kind of dispute. If you tell the code
> monkeys how to implement this exactly, you would quite inevitably do
> cause such a dispute, in a worse form, because behavior that does not
> correspond to user expectations would be backed by a specifcation, and
> people would talk about that instead of using common sense.
>

It is only through the user selecting a file and clicking upload after 
they have received a file dialog that the page has access to anything 
sensitive. If you receive an unsolicited file picker randomly, mid-flow, 
when you visit a web page it is confusing so you click cancel, right? It 
is a web page's responsibility to make the user aware what it is they 
require and therefore what is about to happen from their own in-page UI 
('Click this button to upload an image from your hard disk to foo.com').

Unbinding the non-synthesized click behavior from an unstylable HTML 
Element like the file upload control also conveniently lets web pages 
define their own in-page UI for file upload - something which a number 
of web sites take advantage of today only through technical hackery e.g. 
a web site can present a nice in-page UI button for the user to click 
but layer an invisible file picker over the top and then jack the user's 
click to invoke the file picker, for example.

It is the UAs responsibility to ensure that those dialogs can only be 
invoked from user clicks rather than clicks synthesized by the web page 
itself. It's this part that we are trying to establish in prose.

> You don't need a centralised definition for this either, if you feel
> the above sufficiently conveys the your ideas, on the contrary, if the
> idea is "make this like this file upload thing", everybody will under-
> stand that much better than when you start referencing "dblclick". And
> if that is not what you mean, then you failed to convey your ideas to
> my humble self, in which case "dblclick" doesn't do you any good either.
> User intent is between the user and the user interface, you can't get
> below that from a lower level specification that relies on the UI, it
> would be a layering violation.

I disagree with that. There's actually an established, mostly 
undocumented, paradigm here to invoke a dialog only if the user clicks 
something on the page rather than that click being synthesized 
somewhere. Then the UA is required to play a role in brokering the 
resulting dialog but that is beyond the scope of a W3C spec and beyond 
the scope of this discussion. It's the first part we wanted to establish 
somewhere.

Received on Wednesday, 7 September 2011 09:06:02 UTC