25365 2014-04-16 12:17:53 +0000 About trusted="false" in two event orders 2014-05-06 00:43:07 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED P2 normal --- 1 crimsteam garykac bugs garykac mike travil www-dom public-webapps-bugzilla oldest_to_newest 103960 0 crimsteam 2014-04-16 12:17:53 +0000 In two event orders: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#events-activation-event-order https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#legacy-uievent-event-order we have trusted="false", but what is trusted? Should not be isTrusted attribute? If yes, then the other site, why in this orders click is not treated as trusted? For example, in FF and IE, when we move focus to <button> and press 'Enter' or 'Space' we get synthesized click event with isTrusted="true". In FF the same will be for synthesized DOMActivate. Chrome doesn't support isTrusted property. Simple 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) </script> 104236 1 travil 2014-04-23 00:57:41 +0000 Mmmm, maybe a holdover from an earlier "trusted" spec. I'll see about making this consistent. 104237 2 garykac 2014-04-23 01:01:01 +0000 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" 104511 3 garykac 2014-04-27 20:14:24 +0000 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? 104512 4 crimsteam 2014-04-27 20:33:30 +0000 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. 104516 5 bugs 2014-04-27 22:41:12 +0000 (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. 104517 6 crimsteam 2014-04-27 23:06:37 +0000 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. 104591 7 travil 2014-04-28 22:09:02 +0000 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.) 104600 8 travil 2014-04-28 22:26:44 +0000 Tried to address this in: https://dvcs.w3.org/hg/dom3events/rev/ddb380ad70de 104880 9 crimsteam 2014-04-30 23:11:53 +0000 C.1.1 Activation event order (second order): 3. DOMActivate default action, if supported by the user agent; synthesized; isTrusted="false" not isTrusted="true"? 105141 10 travil 2014-05-06 00:43:07 +0000 Oh, thanks! Followup changelist: https://dvcs.w3.org/hg/dom3events/rev/0e86d968e9d4