- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Thu, 13 Feb 2014 01:59:13 +1100
- To: James Greene <james.m.greene@gmail.com>
- Cc: Domenic Denicola <domenic@domenicdenicola.com>, "public-webapps" <public-webapps@w3.org>, olli@pettay.fi, Jonas Sicking <jonas@sicking.cc>, Hallvord Steen <hsteen@mozilla.com>, Maciej Stachowiak <mjs@apple.com>
On Sat, 8 Feb 2014, at 12:19, James Greene wrote: > There are certain situations where sync XHRs are, in fact, required... > unless we make other accommodations. For example, in the Clipboard API, > developers are allowed to inject into the clipboard as a semi-trusted > event > during the event handling phase of certain user-initiated events (e.g. > `click`).[1] This has not yet been implemented in any browsers yet. > > However, if browser vendors choose to treat this scenario as it is > treated > for Flash clipboard injection, then the semi-trusted state ends after the > default action for that event would occur.[2] > > For Flash clipboard injection, this means that any required "on-demand" > XHRs must be resolved synchronously. For the DOM Clipboard API, it would > be > nice to either still be able to use sync XHRs or else we would need to > specially authorize async XHRs that are started during the semi-trusted > state to have their completion handlers also still resolve/execute in a > semi-trusted state. Couldn't the semi-trusted state be kept for any promise created while the semi-trusted is set? In other words, promises could keep the semi-trusted state along the chaining. Though, as Olli said, this is something the Clipboard API specification should fix. -- Mounir
Received on Wednesday, 12 February 2014 14:59:57 UTC