This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At now, for click() method when invoking from a script we have: [Fire a click event at the element. If the run synthetic click activation steps algorithm was invoked because the click() method was invoked, then the isTrusted attribute must be initialized to false.] But in all other methods, like focus(), blur(), submit(), start(), stop(), pause()..., events have isTrusted="true". The same is in other spec (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25498). Why this click() method is so special and set untrusted click event? In the other site, at now .isTrusted allows us to distinguish only those events sent via EventTarget.dispatchEvent() + click() method? We can't identify those that are invoked by the methods directly frome the script (which potentially look like untrusted). BTW, IE11 for click() method has isTrusted="true". Definition .isTrusted: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#widl-Event-isTrusted http://dom.spec.whatwg.org/#dom-event-istrusted
Click is not trusted so that it can't open popups. I'm not sure it matters for the other events, in practice, but maybe someone has an opinion?
Hmm, so now we can't detect that some event are derived from methods inside the script (not user interaction or normal action user agent), what looks like a slight limitation for developers.
The only opinion I have is that it should be defined. Part of that is someone actually taking the time to properly define UI events, as per http://lists.w3.org/Archives/Public/www-tag/2014Apr/thread.html#msg26
So I'm not sure what should be done here. Maybe it would help to look at this from a concrete perspective. What is it you want to do that you can't do today?
Actually, reading comment 0 closer, I thought the other idea behind trusted was that you could be sure the event was initiated by the user agent in response to user input. Meaning the trusted flag should never be set for events dispatched as the result of invoking some method. Am I misremembering?
Simply there is no easy way to reject events from the script when using these methods. But in my experience the event detection directly from the script would be very helpful (not only EventTarget.dispatchEvent()), especially in the popularization of web platforms. At this moment we can't prevent a synthetic actions performed by the third party softwares (injected scripts, addons, etc. ...), when we require only the real user actions. At first I thought that .isTrusted cover this cases, but in reality corresponds only to the EventTarget.dispatchEvent() + click(). Perhaps trying change .isTrusted is not the best solution (support in Firefox and IE and return 'true' for most this method), but any sensible way for detect these events would be useful in future.
We could make focus(), submit(), et al set isTrusted to false, if that's Web-compatible. Any vendors have any opinions on this?
I think it would be better if I open this bug in the DOM or DOM3 Events because it applies to a wider area than the HTML. A simple changing .isTrusted='false' for some events generated by methods doesn't fit to the D3E definition (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#trusted-events) when events have default action and may be risky for web-compatible. So if no one has anything to add please close this bug, and if in the future something will change I reopen it again.
https://github.com/search?l=javascript&q=istrusted&ref=cmdform&type=Code https://github.com/search?l=html&q=istrusted&ref=cmdform&type=Code seems to be mostly test cases from a quick look. webdevdata data set 2013-09-01 102,000 pages has 0 occurrences of ".isTrusted". Since WebKit/Blink don't support this yet, maybe we can still change it? Should it be false for everything except user-initiated events, e.g. the 'load' event? For some events it's a bit fuzzy, e.g. the 'resize' event gets fired when the user resizes the window, but what about when a script resizes an iframe? What about when an iframe gets resized because the user resizes the parent window?
The problem with .isTrusted is also that it can express only two values (true/false), and for determining the origin of the event is very limitation. Events should have some extra attribute, like e.origin, e.source, or just e.infos, without the possibility of any change ([Unforgeable], like .isTrusted), from which we could read the important information: 000 - default, without any important infos (standard cases, for example when UA process document) 001 - generate from script by using constructor or document.createEvent() 010 - generate from script by using method focus(), blur(), submit()... and if any problem would arise in the future then more bits might be define, like: 100 - generate directly from user interaction Or something equivalent, which could be (if necessary) expanded. But if it is unrealistic and no one would be interested then maybe adapt .isTrusted is the only solution, at least for some of the methods, because they simulate user interaction and now can't be identified.
Fundamentally, events that were triggered by author script should not be trusted, and events that were triggered by the user agent are trusted. Historically it's only really been used for preventing popups, so it only really mattered for 'click' and company. But I agree that we should be consistent for other events.
It will matter for components.
Can you elaborate on that?
Once we have components that are isolated from the page, the component wants to distinguish user input from the page trying to trick it into doing something. Similar to how UA-components do the same thing now.
Ah, yes. That makes sense. That's mostly for UI events though, which this spec doesn't trigger. This bug is about events fired by methods like: focus(), blur(), submit(), start(), stop(), pause(). But actually, all of those _should_ IMHO be trusted, because they represent cases where the UA really _is_ doing the action. It's still the UA firing the event, not the page firing it, if you see what I mean. To look at if from a component's point of view: there's a difference between being blurred because someone called .focus() on something else, and receiving a fake 'blur' event. There's no differerence between being blurred because someone called .focus() on something else and being blurred because the user clicked on something else. So, I guess I should go through the spec on a case-by-case basis checking to make sure the right events are trusted, but off the top of my head I can't think of any that are trusted that shouldn't be, right now.
I guess I can see that. I guess what's missing is "was focus() called as the result of a user action" which is what we have to disable popups. But that might give away too much information to malicious pages.
You can't show a popup from a 'focus' event anyway. The events you can show a popup from are: change click dblclick mouseup reset submit I guess some of those need to be marked non-trusted when fired from script, though. That's a good place for me to start work on this bug.
Checked in as WHATWG revision r8718. Check-in comment: Make sure reset() can't fire a popup http://html5.org/tools/web-apps-tracker?from=8717&to=8718
The submit and click firing already checked for cases where APIs triggered them. Trusted mouseup and dblclick events can't be fired by script. I just fixed reset. Looking at change now.
Checked in as WHATWG revision r8720. Check-in comment: Block popups from some weird edge cases that fire 'change' events on <select> as a result of script. http://html5.org/tools/web-apps-tracker?from=8719&to=8720
Ok, that addresses the change event too. If there's anything I missed, please file a new bug describing the problem. Thanks!