Phase2Results.php" ); ?> Browser Unresponsive Mode Enhancements - RuntimeWiki

Browser Unresponsive Mode Enhancements

From RuntimeWiki

Jump to: navigation, search



Browser "unresponsive mode" enhancements

Detailed write-up


Most current browsers suffer from one or more ways to make a browser window unresponsive, be it caused intentionally or accidentally by the page's code. An unresponsive window can be characterized by:

  • the browser window controls not being responsive (resize borders etc)
  • the browser chrome not being responsive (back/forward buttons, address bar, etc)
  • the page content not being responsive (clicking links, edit text fields etc)
  • the page content not being repainted when needed (f ex after window being obscured)
  • animated GIFs not animating
  • custom event handlers not called at the appropriate time (timeouts, input events etc)
  • or all of these at the same time.

Some of the unresponsiveness types described above will only appear on certain platforms, unresponsive window controls on MS Windows (where an application, unlike in X-Windows, may hang window manager operations).

Typical causes of the unresponsiveness include:

There are also variations on these themes where an evil page designer (or a careless web developer, maybe yourself ;-) makes a timeout (0 msec) that pops up alerts that will make it impossible to navigate away from the page - only solution being to kill the browser process.

Of course, some of the mentioned causes introduce certain unresponsiveness types by intentional design:

  • can't run custom event handlers while a long script is executing due to JS single threading
  • unresponsive page content is desired while showing a modal dialog

but there are many other unresponsiveness types that could be mitigated by improved browser designs.

Why Is This Important?

A GUI (page) that doesn't respond or repaint as expected ruins the user experience.

Possible solutions

All of the below would be desired:

1. Let browser window and chrome be handled on a thread separate from page scripts, to allow the former to respond while the latter executes a long script.

2. Make modal dialogs only lock out interaction with page content while still allowing interaction with browser window and chrome.

3. Let the single JS thread be "reused" when waiting for input in a native library call, to execute UI repainting, run animated GIFs and maybe run some custom event handlers like timeouts and UI repainting related stuff. F ex this would apply to:

  • alert (modal dialog): most factors mentioned here are already solved in current browsers but browsers do differ whether f ex a timeout is triggered during the modal state. Also, when (2) allows window interaction during modal state, then we would f ex want resize event handlers to trigger while the dialog is shown.
  • synchronous XHR: here there is need for improvement in most browsers on all the factors mentioned (browser window virtually hangs). A specific case (that is also mentioned in Synchronous XHR Enhancements and JavaScript Coroutine Support) is making use of synchronous coding with XHR. If timeout event handlers were allowed to trigger while hanging in the synchronous call then it would be possible to implement your own timeout for sync XHR by calling XHR.abort() after the desired elapsed time.

Optionally, there could also be a syntax for specifying the desire to also have custom input event handlers like mousemoves etc trigger during these cases, but I'm not so sure about the usefulness of this.

4. Let the "Stop" button abort long scripts and modal states in the following way:

  • one click on Stop aborts the currently executing JS function, possibly by throwing a catchable AbortedException from the current program location, allowing the page to handle the exception.
  • a second click on Stop aborts the currently executing JS function in a non-catchable way and also disables the execution of all custom event handlers in the page, so f ex code triggered from timeouts or input events can't "lock" the page again.

5. Let navigation actions like clicking Back or Forward, typing new URLs in the address bar or activating bookmarks abort long scripts and modal states. There could be confirmation questions like:

  • "The current page is still running a script. Are you sure you want to navigate away to a new page?"
  • "The current page still has an open dialog box. Are you sure you want to navigate away to a new page?"

6. "Brute Force" dialog box prevention. After X dialogs in Y seconds, throw javascript errors instead of displaying the dialogs, allowing the interface to be responsive again. At the end of Y seconds, reset the dialog counter.

  • Example: Script requests 15 dialogs in a 60 second time period. Obviously this should be detected as a javascript error, and necessary javascript errors should be thrown. This frees up the browser interface, allows the developer to see proper error messages, and prevents unnecessary annoyances to users.

Background material that request this feature

This suggestion touches on some of the same subjects as discussed in JavaScript Coroutine Support, though from a different angle.


In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section

Jon Ferraiolo comments

Great suggestions!

T.J. Leahy comments

The Modal Dialog suggestion is perhaps the most important here. I think everyone has used alerts for debugging only to end up having an endless stream of alerts preventing you from navigating away from the page, requiring either a browser restart or careful mouse/keyboard timing. A possible solution would simply be a modal box frequency timer in the browser, almost like brute-force prevention systems, limit modal dialogs to only X occurrences in Y seconds, and throw javascript errors after that.

Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I

Votes on the following wiki page:

Phase II Voting

More about this later.

Personal tools