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" <[email protected]
<mailto:[email protected]>> wrote:
On Feb 7, 2014, at 9:18 AM, Jonas Sicking <[email protected]
<mailto:[email protected]>> wrote:
On Feb 7, 2014 8:57 AM, "Domenic Denicola" <[email protected]
<mailto:[email protected]>> wrote:
>
> From: Olli Pettay <[email protected]
<mailto:[email protected]>>
>
> > 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
