W3C home > Mailing lists > Public > public-webapi@w3.org > June 2006

Re: [DOM3EV] introduce Event.trusted? (ISSUE-10)

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Sun, 25 Jun 2006 11:14:47 -0500
Message-ID: <449EB677.508@mit.edu>
To: Jim Ley <jim@jibbering.com>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

Jim Ley wrote:
> User agents will need to provide API's for their 
> plugins that can distinguish between the 2 cases of user and non-user 
> provided events


> an Access Technology must be producing events that are 
> trusted, or it would hobble AT's.

Yes, Gecko provides C++ callers with an API for dispatching trusted events.

> There's also a lot of development of AT's that are simply scripts 
> included in the page, these would have no mechanism of creating trusted 
> events, and would in effect hobble these scripts entirely.

If they need to produce trusted events, they may request expanded privileges in 
Gecko.  If the user grants them, then they can produce trusted events (and do 
some other things, at the moment; perhaps there should be a separate privilege 
level for producing trusted events but nothing else...  except that it's hard to 
control what pages can do with trusted events; see below).

> What are the use cases?

The primary use case that originally motivated this change in Gecko is very 
simple.  If the user hits "Alt-F", we want the File menu to open.  We do NOT 
want it to open if some random web page synthesizes a keypress event for the 
letter "F" with the "alt" modifier set.  The menus are just driven by the DOM 
events happening in the content area, so we needed to differentiate the two 
types of events.

The current use cases in Gecko are, in addition to the above:

1)  Allowing browser extensions to decide whether to listen to all events
     or only trusted ones; whatever their reasons for it.
2)  Only allowing middle-mouse paste into an editor if the middle-click
     event is trusted.
3)  Some XForms stuff I'm not familiar with.
4)  Some XBL stuff.
5)  Text input and textarea only respond to trusted events (not sure why;
     would need to dig in the CVS history).
6)  Anchor default actions (showing text in the status bar and following
     the link) only happen for trusted events; I believe the status bar
     part was why this was done...
7)  Untrusted events do not put the popup blocker into the "user actually
     did something like clicking a button, which means he may want a new
     window" mode.

Received on Sunday, 25 June 2006 16:14:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC