Re: trusted property

Siterer Olli Pettay <Olli.Pettay@helsinki.fi>:

> trusted is defined in XBL2, and IMO
> it would make sense to expose that to all events, also
> in platforms which don't support XBL2.

I accept your opinion though I don't fully understand the use case :)
Why would an event listener on a web site need to rely on the  
"trusted" property? I'm not really arguing against it being in the  
spec or anything, I'd just like to understand this better.

>> I'm not sure what the use case is for exposing a "trusted" property to
>> normal scripts. It also seems rather draconian to say that "All other
>> untrusted events must behave as if the Event.preventDefault() method had
>> been called on that event". This comes right after a sentence saying
>> "should not trigger default actions". So is this a "should" or a "must"
>> requirement for an implementor?
> This is actually a bit tricky, because IIRC, because of backward
> compatibility dispatching key events should trigger default action at
> least in some cases, i.e. when dispatching events to <input> elements or so.

Indeed. Either it should be defined in more detail regarding what  
events should cause default actions to happen when dispatched from  
scripts, or it should explicitly be left up to the implementation..

>> Also, it may need to say that setting properties directly on the event
>> object should change event.trusted to false? E.g. some browsers let me
>> set event.keyCode for a key event. Having done that the event is
>> presumably no longer "trusted"?
> keyCode should be readonly property.
>
> And setting properties to a trusted event shouldn't change its status.
> I assume platforms would internally still check whether it is trusted
> or not and use the original values.

I'm looking at a bug report saying we should allow setting keyCode  
(and/or charCode?) and let the value set from script affect the text  
produced in order to be compatible with JS-based "virtual keyboards" -  
so I assume that at least some major browsers support this? I have not  
yet had a close look at the code to see how they do it for Gecko-based  
browsers.

Regarding the "trusted" property - in your answer you assume that only  
the UA really needs to rely on this information for its internal  
processing. I agree with that - but then we're back to the question of  
why it is exposed to scripts, particularly if "trusted" doesn't even  
guarantee that the event has not been "tampered with"..

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Wednesday, 3 March 2010 16:20:43 UTC