- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Wed, 03 Mar 2010 16:20:05 +0000
- To: Olli Pettay <Olli.Pettay@helsinki.fi>
- Cc: www-dom@w3.org
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