W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 24 Apr 2012 15:34:37 -0500
Message-ID: <CABirCh9pwTRM7XB1kbzaGLbN+SbVcsx+=OqmJM+5y6aG2kd9Fg@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: Travis Leithead <travis.leithead@microsoft.com>, "olli@pettay.fi" <olli@pettay.fi>, "public-webapps@w3c.org" <public-webapps@w3c.org>, "Anne van Kesteren (annevk@opera.com)" <annevk@opera.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>
On Tue, Apr 24, 2012 at 3:06 PM, Tobie Langel <tobie@fb.com> wrote:

> Are you asking about the purpose of exposing the property or the purpose
> of trusted events?

I'm asking about the property.  The flag underneath it exists only to
implement the property.

The latter's obvious: prevent visited content from triggering actions the
> UA wants to allow only after a user action. The former I'm not sure.

This is a common misconception of how events work.  If you're a browser,
default events do not--except for one or two web-compat exceptions--look
like this:

browse_button.addEventListener("click", function(e) { if(e.isTrusted)
openFilePicker(); }, false);

Rather, they look like this:


The "default action"--openFilePicker()--is not part of the event dispatch
process; it's part of the caller of the dispatch.  You don't need a flag to
tell you that you dispatched the event.  (DOM3's language about "default
actions" confuses this; I suggest reading DOM4's event section to get a
good picture of how this actually works.)

(The main exception is the "click" event, which does activate the element
when a synthetic event is dispatched.  This is a historical mistake, not
the norm.  I don't believe that needs this flag, either, but I'll hold off
explaining why unless somebody asks.)

Glenn Maynard
Received on Tuesday, 24 April 2012 20:35:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC