Good old Firefox
Filed under: Discussion, Firefox
By Thomas Herchenröder @ February 1, 2008 4:43 pm
Ok, so this is a rather personal rant about my frustration with current Firefox. Firefox is my bread-and-butter tool every day. I don't know how you feel, but my impression is that Firefox falls behind in a central issue for browsers, speed and responsiveness. As a real-time, GUI-based, highly user-interactive, networked tool, a browser has to be top notch in handling concurrency. This is not exceptionally good in Firefox 2, and I can only hope it will improve significantly in the upcoming Firefox 3, with a new rendering engine and - more importantly - a threadmanager (see here). It seems the new theme gets all the attention but I don't care about themes when the reponsiveness is poor. Maybe Webkit is the new hot shot, and I would be interested if they'd released it on Linux.
The issue is, I have easily three browser windows open at any one time, with a total of 20 to 30 open tabs in them. I switch between windows and tabs, starting page loads in one and continue reading in another. And I regularly are blocked by the browser itself. I accept network latency, but why is one window not repainted while the other is loading? Why can't I switch tabs when a script starts in the other? Or why can't I open my preferences window while the browser is loading? Why is Firefox always getting in my way?
My concerns with current Firefox are:
- Page loading. It's not understandable the browser is not able to load pages in the background. Or more practical, why can't I switch to another tab reading what's already there while the browser is loading and rendering a new page in the tab I'm about to leave?!
- Multi-threaded Javascript host engine. I don't see why you couldn't have a multi-threaded Spidermonkey whith a thread for every web page that uses Javascript. This way you could isolate the pages against each other, while handling concurrency so that every page has optimal responsiveness.
- Power to the chrome, which means power to the user. In a multi-tasking browser, the UI has to have top priority. User interaction is always more important than everything else. If I open a menu or invoke a dialog or operate some other control of the chrome, the browser has to respond immediately no matter what it is doing at that time. Loading, rendering, cache management, execution of scripts - you name it, they have to wait.
So, it boils down for me to this: I want a multi-tasking browser with decent (pre-emptive) task scheduling and priorities. Just like a decent operating system. But task management is not only for OS's, the technology is since long available for every application to implement.
Comment by Oliver
There are a number of problems in making JS multithreaded, the most significant being the fact the JS in one window can interact with JS in another, so making JS multithreaded would require a significant amount of work due to the additional locking, etc that would be required. All that locking would have a relatively severe impact on JS performance, at least when accessing the DOM.
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 :-/
February 1, 2008 11:44 pm
Comment by Thomas Herchenröder
I’m hopelessly late on this one, but there you go…
@Oliver: Thanks for your elaborate comment. Just a few remarks:
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.
March 19, 2008 10:34 pm
Pingback by qooxdoo » News » Chrome - a browser designed for qooxdoo
[...] second ground breaking feature is threaded browsing. In February Thomas has written a nice article about why Firefox should support one JavaScript interpreter per tab. Now a few months later Chome [...]
September 2, 2008 11:58 pm