W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2010

Re: trusted property

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 03 Mar 2010 18:41:53 +0200
Message-ID: <4B8E9151.2030001@helsinki.fi>
To: "Hallvord R. M. Steen" <hallvord@opera.com>
CC: www-dom@w3.org
On 3/3/10 6:20 PM, Hallvord R. M. Steen wrote:
> 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.

Use case is that XBL2 widget is provided by some other "domain" than
the page. Especially if the widget is from UA, it needs to be able to
check if the event is user initiated so that the widget can prevent
the page to do evil things like unwanted popups.


>>> 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"..
Received on Wednesday, 3 March 2010 16:42:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:56 UTC