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

On 02/08/2014 03:19 AM, 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.
>

Doesn't sound like a case where we should allow the horrible sync XHR to run.
If really needed, we can add something to clipboard API to let it deal with asynchronous loading.





> cc: Hallvord R. M. Steen
>
> [1] http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
>
> [2] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/desktop/Clipboard.html#setData()
>
> Sincerely,
>      James Greene
>      Sent from my [smart?]phone
>
> On Feb 7, 2014 2:55 PM, "Maciej Stachowiak" <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>
>
>     On Feb 7, 2014, at 9:18 AM, Jonas Sicking <jonas@sicking.cc <mailto:jonas@sicking.cc>> wrote:
>
>>     On Feb 7, 2014 8:57 AM, "Domenic Denicola" <domenic@domenicdenicola.com <mailto:domenic@domenicdenicola.com>> wrote:
>>     >
>>     > From: Olli Pettay <Olli.Pettay@helsinki.fi <mailto:Olli.Pettay@helsinki.fi>>
>>     >
>>     > > And at least we'd improve responsiveness of those websites which stop using sync XHR because of the warning.
>>     >
>>     > I think this is a great point that makes such an effort worthwhile even if it ends up not leading to euthanizing sync XHR.
>>
>>     Agreed. I think for this to be effective we need to get multiple browser vendors being willing to add such a warning. We would also need to add
>>     text to the various versions of the spec (whatwg and w3c).
>>
>>     Which browsers are game? (I think mozilla is). Which spec editors are?
>>
>     I usually hate deprecation warnings because I think they are ineffective and time-wasting. But this case may be worthy of an exception. In
>     addition to console warnings in browsers and the alert in the spec, it might be useful to have a concerted documentation and outreach effort (e.g.
>     blog posts on the topic) as an additional push to get Web developers to stop using sync XHR.
>
>     Regards,
>     Maciej
>
>
>

Received on Saturday, 8 February 2014 01:52:43 UTC