Firefox chrome could be run in its own JS thread, with a guaranteed priority. This alone would make the browser more useable since it decouples the UI from JS running in pages.

‘Unrelated’ pages could run their own JS thread. It might take a bit of figuring out how to exactly determine ‘unrelatedness’. But we want some kind of sandboxing anyway, and I don’t see a reason why a page loaded from Google and another from Amazon should share anything. It might be too narrow to set unrelated = different windows/tabs, since the JS in one window can open another (sort of a ‘child’ window) and you want to maintain some connection here. Having a common thread for those seems fine. But other than that?!

Plugins should run in their own threads. If they access a loaded page, yes, locking has to be in place. But since the only data that is contested is the DOM/BOM, this should be doable. E.g. since the browser offers all the APIs, those API calls could be made atomic.

As for event handlers: I don’t see an issue here, since the page itself can remain single-threaded. So all code you throw into your page, handlers included, behave the way they did before, synchronous xhr requests blocking and everything. And the risk of any computation being exempted is there already, when you get this pop-up saying “This script takes too much time. Do you want to interrupt it?”. Data loss and failing server communication are always possible and should be encapsulated in a transactional protocol on the application level. Still, you could make running event handlers within a page atomic so other threads cannot mess around with them.

And most of all: You could kill a JS thread without killing the whole browser :-).

I do agree with your point that Web developers have to be more thoughtful with respect to their users, though. But again, with a thread for every page, even a synchronous xhr would be acceptable again, since chrome and other pages continue to work while this one page is waiting for the request to return. And this could make some issues in web applications feasible again, when you actually need synchronicity.

The other issue is handling events — if my page is running a long and complex script, what happens to things like event handlers during that time? For example if i have an onload handler that modifies the state of the enviroment (eg. sets a variable) that shouldn’t be allowed (JS is not expected to be threaded) but what happens if i click a link? it turns out you still can’t respond as that may interrupt a synchronous xhr and result in data loss. How do you scroll if there’s an event handler on the scroll event?

Opera appears to have resolved these issues, although exactly how safe their solution is is difficult to gauge due to the low market share (so you don’t see much noise). All the other major browsers (Safari, Firefox, IE) just execute JS directly on the UI thread as this is how JS was originally defined, and is the easiest way to ensure the event handlers, etc act in the expected way. The problem with this is that web developers are not always the most careful of engineers.

A common problem is that a developer will do computation in JS that works fine on their high end machine, but on a low end machine takes significantly longer. In ordinary applications that’s annoying, in web applications due to the JS running on the UI thread the extended runtime prevents the user from using their browser. Other common mistakes are the use of sychronous io — eg. synchronous xhr — which works fine for the developer who is testing behaviour as the may be using smaller data sets, have faster than average connection, etc. The net result is that they see no interactivity problem, but real users with real datasets end up hit issues where their entire browser has locked up (synchronous xhr blocks JS, which in turn blocks the UI).

In firefox it is more complicated as the chrome is driven by JS, as are extensions, and all this JS can technically interact with the page. I would guess this makes it event more difficult for firefox to make the js interpreter multithreaded.

It is because of the tendency for developers to make such assumptions that the new html5 database API’s are *all* asynchronous.

…

Errr, that ended up being a somewhat longer comment than i intended :-/