- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Sun, 25 Jun 2006 11:14:47 -0500
- 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
Yes.
> 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.
-Boris
Received on Sunday, 25 June 2006 16:14:54 UTC