Re: [xhr] responseType for sync requests in window context

2012/1/26 Mark Callow <callow_mark@hicorp.co.jp>

>  I do not think you should be in the business of brute-forcing authors
> into converting their applications to use async XHRs. As far as I
> understand it, it is the application's UI that may be unresponsive during a
> sync XHR. In that case it should be the app. authors choice which to use.
> If it is the browser's UI, that is a bug in the browser.
>
The point is to only affect XHR when new features are used, so the amount
of affected existing code is small.

> Since this change principally affects WebGL app's it would have been nice
> of someone to have mentioned this change in the public-webgl mailing list
> while it was still at the proposal stage.
>
There's nothing WebGL-specific about it, so there's no reason anyone would
raise it on WebGL lists.

>  For the record the change has broken all our WebGL applications. Forcing
> us to jump through the hoops of using async XHRs is going to have zero
> impact on the user experience in our case because the 3D itself is the UI.
> Until its loaded there is nothing the user can do.
>
Of course it impacts the user's experience.  You can't open context menus
in most browsers; in Chrome you can't hit browser back; browser UI for the
tab in general simply pauses.  You can't do a lot of things while a sync
XHR is taking place, because they require doing things that, both per spec
and sane API design, can only take place during the event loop and not
while JavaScript code is executing.

> If sync XHRs are so bad, why to they exist?
>
Because they were added long ago, before browser developers figured out
that sync APIs in the UI thread are bad.  There's a reason no new APIs
outside of workers have sync interfaces.

-- 
Glenn Maynard