- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Sat, 08 Feb 2014 03:52:12 +0200
- To: public-webapps <public-webapps@w3.org>
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