4/15/2008 10:08:24 AM

Jon, as far as I understand, this behavior can't be changed. JavaScript is single threaded, so if you state that request must be done in synchronous manner, then this only app thread should wait for request completion. Maybe you may scroll page during this delay, but I'd prohibit clicking, because it could be related to JS handlers that could not execute because thread is locked.

Andrew Mayorov

4/15/2008 7:53:25 PM

Javascript is single-threaded, but single-threaded runtimes can be inturrupted by message pumps (mouse click, AJAX response, etc). You can also isolate the Javascript thread from the HTML renderer thread, and likewise you can seperate either or both contexts from the UI thread that the browser shell (operating system) is operating under.

I know that it's possible because Opera managed to pull it off, which is quite fantastic.

Jon Davis

4/16/2008 3:55:10 AM

If you hit breakpoint in Firebug, then page continues to response somehow. But at the end it anyway got stuck. I think it's better just architect our apps in async manner. We can do it easily, while we can do virtually nothing with browser itself.

Andrew Mayorov

4/17/2008 1:46:56 AM

On the web, async coding is always better, I agree. That's why I've made such an effort to support asynchronosity in using.js, for example.

That said, it's not for me to determine how someone else codes up an app; if, for example, someone is prototyping functionality and they want to litter their app with synchronous code to run on localhost and demonstrate something without detailing it or tuning it for UX, I want them to feel free to use a "quick and dirty" prototyping toolset; more power to them.

Jon Davis