Browser Unresponsive Mode Enhancements
Browser "unresponsive mode" enhancements
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.
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.
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?"
Background material that request this feature
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
T.J. Leahy comments
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.