Mmmm, maybe a holdover from an earlier "trusted" spec. I'll see about making this consistent.

In section 3.5.2 "Activation event order", the comment for 'click' in the example says 'trusted' instead of 'isTrusted'.

Also in C.1.1 "Activation event order"

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?

Oh, I forgot about the chapter "3.4 Trusted events", where this information exist.

Before some changes will be better test more cases in FF and IE, because I check only <button>. Anyway, "untrusted" in this case seems unnecessary complication.

(In reply to Gary Kacmarcik from comment #3)

> 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.


web relies on untrusted click to trigger default handling, at least for
links.

Right, still exist sth like element.click()

http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#dom-click

which generate untrusted event but trigger default action. So description in "3.4 Trusted events" is correct.

Small test:
<button id="btn">Move focus to this button and press Enter/Space</button>
<p style="color: blue;">Detailed information for the captured events:</p>
<p id="info"><p/>

<script>

	var btn= document.getElementById("btn");
	var info = document.getElementById("info");

	function readInfo(e){
	
		var data = "Interface: " + e
			+ "<br>" + "e.type: " + e.type
			+ "<br>" + "e.target: " + e.target
			+ "<br>" + "e.isTrusted: " + e.isTrusted + "<br><br>";
	
		info.innerHTML = info.innerHTML + data;
	
	}

	btn.addEventListener("keydown", readInfo)
	btn.addEventListener("DOMActivate", readInfo)
	btn.addEventListener("click", readInfo)
	
	btn.click();

</script>

But, in IE11 above return e.isTrusted="true" (incorrect with HTML5), when Firefox has "false".

Event orders in cited examples sholud inform if it represented trusted (like manual key press) or untrusted case (call method from script) and everything would be obvious.

In looking through this, we don't see a problem with actually letting the isTrusted value be 'true' for the synthesized (by the user-agent) click events. This would change some of the isTrusted values in examples 3.5.2, and C.1.1. 

(Also we will re-write section 3.4 to be more clear -- it's really hard to read at the moment.)

Tried to address this in:

https://dvcs.w3.org/hg/dom3events/rev/ddb380ad70de

C.1.1 Activation event order (second order):

3. DOMActivate 	default action, if supported by the user agent; synthesized; isTrusted="false"

not isTrusted="true"?

Oh, thanks!

Followup changelist: https://dvcs.w3.org/hg/dom3events/rev/0e86d968e9d4