Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

On Tue, Mar 20, 2012 at 9:09 AM, Gordon Williams <> wrote:
> Hi,
> I recently posted on
> about the change to XHR which now appears to be working its way into
> Mainstream users' browsers.
> As requested, I'll pursue on this list - apologies for the earlier bug spam.
> My issue is that I have WebGL JavaScript that is machine-generated from a
> binary file - which is itself synchronous. It was working fine:
> It now fails on Firefox (and shortly on Chrome I imagine) because it can't
> get an ArrayBuffer from a synchronous request. It may be possible to split
> the execution and make it asynchronous, however this is a very large
> undertaking as you may get an idea of from looking at the source.
> My understanding is that JavaScript Workers won't be able to access WebGL,
> so I am unable to just run the code as a worker.
> What options do I have here?
> * Extensive rewrite to try and automatically translate the code to be
> asynchronous
> * Use normal Synchronous XHR and send the data I require in text form, then
> turn it back into an ArrayBuffer with JavaScript
> Are there any other options?
> Right now, #2 is looking like the only sensible option - which is a shame as
> it will drastically decrease the UX.

I think that there's an option #3, which is to run the code inside a
worker and have it use synchronous APIs.

I agree that trying to automatically rewrite large C++ code bases to
change synchronous call into asynchronous calls is a too difficult
task. If it wasn't I'd love to run such a transformation over gecko to
change it to not use synchronous IO anywhere :-)

But I also think that having the translated code do a pile of
synchronous XHR calls will lead to a too poor user experience, so that
doesn't seem like a good option either.

Hence I suggest that you run the translated code in a worker. That way
you'll also be able to do synchronous file handling like using
FileReaderSync which you're bound to want to use in translated code.

/ Jonas

Received on Tuesday, 20 March 2012 16:48:31 UTC