Analyze isTrusted usage #1912
Comments
|
Is there any case yet where we know |
|
I listed two cases in OP. |
|
Oh, sorry. I thought this was simple in Blink, in that all events start out with Here's a It looks like |
|
In https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4577, all except Edge have |
|
It's still a little bit unclear to me what the use of |
|
Use of isTrusted is that default handling can then check whether the event is from UA. |
|
The If all UA-created events except the ones created inside |
|
I guess, a little unclear what utility it offers to developers, but I suppose it doesn't matter. |
|
Yeah, the |
This aligns firing and dispatching of events with updated terminology in the DOM Standard. Among the changes: * A lot less usage of "default action" which isn't really a thing. Instead we make use of the return value of the fire and dispatch algorithms. * Instead of saying things bubble or are cancelable we initialize the attributes as such. * We no longer re-state defaults for isTrusted, bubbles, and cancelable, as that only leads to confusion when they are *not* re-stated. * We now use the legacy target override flag rather than supplying a named argument. This fixes #1713, but plenty of follow up issues remain: * #805 for the remainder of "default action" usage * #1394 for updating synthetic click events * #1887 for removing "fire a simple event" usage * #1893 for updating when checkboxes get checked * #1900 for figuring out if event dispatch requires more hooks * #1912 for revisiting isTrusted usage * #1913 for updating synthetic mouse events * #1922 for making more events composed
I actually really like this characterization and would support updating DOM to make it the primary definition of isTrusted. Maybe with some nice warning about how the name is historical. |
|
@foolip isTrusted was useful for chrome extensions to determine if the user actually did the action or it was injected by something on the page. |
|
Perhaps I don't follow the spec change. But it seems isTrusted is true most of the time which is entirely incorrect... Here is an example where it is false: |
|
So in general the rule seems to be that whenever the UA dispatches the event, isTrusted = true, and when the web developer does, isTrusted = false. Of course these terms are kind of vague. Presumably dispatchEvent() calls is the web developer dispatching, even though it's UA code inside the dispatchEvent() algorithm that actually dispatches the event. click() is then a sticky case. It seems like in practice it's treated like "basically dispatchEvent()", so is not trusted, even though technically it's again UA code doing the dispatch. But in all other cases where the UA dispatches the event, it's trusted. |
|
That is precisely the way I implemented it. Synthetic clicks are slightly On Oct 19, 2016 16:25, "Domenic Denicola" [email protected] wrote:
|
Closes #1602. Browsers already behave this way, and it is more consistent with how the rest of the spec almost always fires trusted events. See also #1912. In terms of spec mechanics, this is done by using the new "create an event" hook from DOM, which sets isTrusted to true for us. This helps with #1789.
<form>.reset() is trusted by browsers. One cannot trigger “send select update notifications” from script as far as I can tell. Fixes #1912.
<form>.reset() always sets isTrusted in current implementations, so we remove the spec language that sometimes set it to false. One cannot trigger “send select update notifications” from script, so the spec language that sometimes sets isTrusted to false for those events can never be triggered, and is thus be removed. Fixes #1912.
Per suggestion in whatwg/html#1912 (comment).
Per suggestion in whatwg/html#1912 (comment).
This aligns firing and dispatching of events with updated terminology in the DOM Standard. Among the changes: * A lot less usage of "default action" which isn't really a thing. Instead we make use of the return value of the fire and dispatch algorithms. * Instead of saying things bubble or are cancelable we initialize the attributes as such. * We no longer re-state defaults for isTrusted, bubbles, and cancelable, as that only leads to confusion when they are *not* re-stated. * We now use the legacy target override flag rather than supplying a named argument. This fixes whatwg#1713, but plenty of follow up issues remain: * whatwg#805 for the remainder of "default action" usage * whatwg#1394 for updating synthetic click events * whatwg#1887 for removing "fire a simple event" usage * whatwg#1893 for updating when checkboxes get checked * whatwg#1900 for figuring out if event dispatch requires more hooks * whatwg#1912 for revisiting isTrusted usage * whatwg#1913 for updating synthetic mouse events * whatwg#1922 for making more events composed
Closes whatwg#1602. Browsers already behave this way, and it is more consistent with how the rest of the spec almost always fires trusted events. See also whatwg#1912. In terms of spec mechanics, this is done by using the new "create an event" hook from DOM, which sets isTrusted to true for us. This helps with whatwg#1789.
<form>.reset() always sets isTrusted in current implementations, so we remove the spec language that sometimes set it to false. One cannot trigger “send select update notifications” from script, so the spec language that sometimes sets isTrusted to false for those events can never be triggered, and is thus be removed. Fixes whatwg#1912.
Other than
click()and<form>.reset()most user-agent-dispatched events should haveisTrustedinitialized to true.E.g.,
EventSourcedispatching untrusted message events seems suspect and probably wrong.The text was updated successfully, but these errors were encountered: