[Bug 25365] About trusted="false" in two event orders

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25365

--- Comment #3 from Gary Kacmarcik <garykac@google.com> ---
trusted -> isTrusted fixed in ED:
https://dvcs.w3.org/hg/dom3events/rev/abc0008f9a1d

As for the larger issue for *why* they are untrusted, I agree that this looks
odd.

The trusted/isTrusted attribute was added in 2010, and started out with the
exception for click and DOMActivate:

"Most untrusted events should not trigger default actions, with the exception
of click or DOMActivate events which have been synthesized and are managed by
the user agents event as the default action of an activation trigger (see
Activation triggers and behavior for more details); these user-agent-managed
synthesized events have a have a trusted attribute value of false, but still
initiate any default actions. All other untrusted events must behave as if the
Event.preventDefault() method had been called on that event."

(see http://www.w3.org/TR/2010/WD-DOM-Level-3-Events-20100907/#trusted-events)


I don't know what the motivation was here, but it seems a weird exception:
* untrusted events shouldn't cause default actions
* click/DOMActivate synthesized events should be untrusted but still need to
cause default actions.

So, I don't see why the synthesized click/DOMActivate events shouldn't be
trusted. Then these events would be consistent with other events in terms of
causing the default actions. Especially if FF/IE are currently generating these
as trusted.

Is there some context that I'm missing for why click/DOMActivate have these
exceptions in the spec?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 27 April 2014 20:14:25 UTC