- From: Hallvord R. M. Steen <hsteen@mozilla.com>
- Date: Tue, 18 Feb 2014 05:12:02 -0800 (PST)
- To: James Greene <james.m.greene@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Ryosuke Niwa <rniwa@apple.com>, WebApps WG <public-webapps@w3.org>, Jon Rohan <rohan@github.com>
So, the story so far is that the spec has added something it labels "semi-trusted events" - that is an event triggered from a trusted event of a whitelisted type. The precedence here is popup blocking - browsers already have rules for which events are "more trusted than others" in terms of likely expressing user intent. (An example makes this clearer: scripts are typically allowed to call window.open() from a click event listener, but are typically not allowed to call window.open() from an load or mouseover listener.)
However..
> Also, will there be any way for us to feature detect when this is available?
I've still not really been able to come up with a nice way to feature detect these "semi-trusted events".
Good ideas requested and appreciated..
> I'm thinking that just using `document.queryCommandSupported("copy")` and
> `document.queryCommandEnabled("copy")` could return some false positives
> (i.e. the feature is not yet implemented but returns `true` anyway) when
> the user is working within a "contenteditable" element, right?
No idea what the current implementation state of these calls are..
-Hallvord
Received on Tuesday, 18 February 2014 13:12:34 UTC