2012/1/26 Mark Callow callow_m...@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
Please keep in mind that multiple web apps share the same main thread.
While browser's can keep their own UI responsive in the face of
synchronous XHRs, they cannot do the same for other web app, which may
share their main thread with a web app that uses synchronous XHR.
Unfortunately, the web
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
2012/1/26 Mark Callow callow_m...@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
Got some reports of broken C/C++ = JS compilers that relied on sync XHR to
load resources into an ArrayBuffer (simulating fopen), e.g. Mandreel and
Enscripten.
https://bugzilla.mozilla.org/show_bug.cgi?id=716765
https://bugs.webkit.org/show_bug.cgi?id=72154#c43
Is there additional scoping of
