Hacker News Reader

Comment by AshleysBrain | Hacker News Reader

Why do they run javascript on the UI thread?!

How would JavaScript be able to override default event handlers if it weren't tied to the UI thread?

Synchronous XHR will tie up every other browser too--because it's a blocking call, hence the "synchronous"...

A rare example of appropriate use is an onbeforeunload handler that saves your work on a webpage when you close the window, because in this case, asynchronous calls will never complete between the click and the window unloading so you have to synchronously block the unload event handler. Now, go post that on this SO thread [1] and make some points ;-)

[1] http://stackoverflow.com/questions/2088318/is-there-any-reas...

Doesn't Chrome run javascript in its own process for each tab's page? How do they handle overriding default event handlers? Or am I misunderstanding something?

Chrome runs a separate process for each tab, and that process includes the layout engine and the JS engine (V8) running in tandem. V8 has to be able to block the layout engine from rendering, otherwise it will draw invalid page states. The execution model (greatly oversimplifying) is that the browser runs a tight loop that monitors for changes to the DOM state and input events, and then synchronously executes JS code bound to these events (and the native handlers if they are not overridden), finally re-rendering parts of the viewport that become "dirty".

In a browser that isolates tabs into their own processes, like Chrome, try opening a tab for www.google.com and then enter this in your address bar:

    javascript:document.getElementById('lst-ib').onclick=function(){while(1);}

When you click on the search box the entire tab will freeze, because the tab process is stuck inside the JS engine running the infinite loop function we bound to the click handler. It's not a matter of bad browser design, that's how the JS execution model is intended to work.

"Web workers" is the HTML5 proposal for running JS code that does not block the event loop. They do not have direct access to the DOM and can only communicate with JS code in the main event loop via a message passing API.

Duly posted.

http://stackoverflow.com/questions/2088318/is-there-any-reas...

This is how it is supposed to work. JavaScript is single-threaded, and JavaScript execution pauses rendering and event-processing on the page. A synchronous XHR request is just like any other long-running JavaScript: it blocks the UI.

That's direct consequence of how JS/DOM is designed to work. IE is not the only browser that has UI thread tied to JS execution.

Although browser chrome could run in a separate thread, that wouldn't prevent page itself (and any interaction with it) from "freezing".

This is because any interaction with the page is fired as JS events, and if JS is busy, it can't pick those events.

Browser can't react to any clicks (even links and buttons can't be activated, because JS is given chance to intercept and cancel those clicks). Even if you want to leave the page, beforeunload/unload events will get queued.

Also pages need to be refreshed only between JS events (that's how DOM animation works, that's how canvas buffering is specced), so even screen redraw is tricky when JS is executing.

But shouldn't the page at least run in its own thread (or process)? If Javascript hangs, sure the page can hang, but the browser UI should still work and give you the opportunity to terminate or recover. According to TFA, Javascript blocks the UI thread in IE9.

Their own guidelines that they link to [1] says "Do not: call into any 'unknown' code from your UI thread". I don't see why a browser is special and can't keep to that rule - especially a modern browser like IE9.

[1] http://msdn.microsoft.com/en-us/library/dd744765(v=vs.85).as...

By the UI they mean the controls inside of the page, not the browser's UI - your back, refresh and other browser controls still work. The same thing happens if you have javascript that consumes CPU and doesn't return for a long period of time. While the javascript is running controls on the page don't work such as buttons and select lists, but when the javascript finishes the UI thread regains control and responds to input again.

Exactly. Sounds like a flaw in IE 9 that they're trying to pass off as an error on the webpage. If the API / functionality exists it should work and not give you a chance of killing the browser.

Sync XHR should hang the page while waiting for the response. It should not hang the whole browser, but it should pause rendering and event processing on the page - i.e. cause the page to be unresponsive. Otherwise it wouldn't be synchronous.

A different issue is whether the synchronous mode of XHR was a good idea in the first place. But what's done is done.

It's not a flaw in IE it's the same in all browsers they use one thread for javascript and UI updates. IE10 will have Web Workers which can be used to prevent this but using Web Workers still involves programmers making their code work async which is the point of this post.

Reply on news.ycombinator.com