W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: "Officially" deprecating main-thread synchronous XHR?

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Thu, 13 Feb 2014 01:59:13 +1100
Message-Id: <1392217153.19553.82522441.5DB93A3D@webmail.messagingengine.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC