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