[whatwg] salvaging work while navigating away from a web app -- onunload="confirm('save before quitting?')

[timeless]

On Fri, Dec 12, 2008 at 10:01 PM, Martin Atkins <mart at degeneration.co.uk> wrote:
> I think this makes a good case for not allowing any site to create
> browser-modal UI. Could browsers handle confirm() and friends in such a way
> that they only block the contents of the tab, not the whole browser?

sure given many years and lots of rearchitecture.

i suspect chrome and ie8 are closest. anyone else who runs javascript
in process is almost certainly stuck.

> In
> particular, the "close tab" and "close window" features, ideally along with
> things such as "Back", "Forward" and "Home" should still be available.

this is only half doable.

and i really shouldn't have to repeat myself, people who don't
understand this shouldn't be asking about it.

if you do the following:
1. run to completion
2. you don't use multiple processes
3. you run javascript using a typical C based stack/state machine
4. let javascript call to native code

then you have this problem:
javascript calls native code (e.g. confirm()), and can't finalize its
stacks until the dialog is finished.

so instead, you push an event loop.

now, if you let this happen in two windows,

you get:
[top]
[currentEventLoop]
[window-2-confirm]
[pushedEventLoop]
[window-1-confirm]
[normalEventLoop]
[appStart]

at this point, you can't dismiss the window-1-confirm until the
window-2-confirm goes away.
It is possible to try to hide pieces of things, including trying to
close the window, however you're going to end up violating run to
completion, which has traditionally been considered holy.

It's not entirely impossible to try to arrange to close the window or
handle stopping scripts for the page, or renavigate the page, but
you're breaking a number of principles and risk hitting various
security cases which were not at risk before.

there are basically two approaches for solving this, one involves
running JS off the main thread, and the other involves running apps in
multiple processes. Google Chrome and IE8 do the latter. No one likes
the former. The complexity is similar for both approaches (lots of
work), but the risks of the former don't offer much in payoff which is
probably why the groups who've worked on it have all chosen the
latter. (AFAIU, mozilla is looking to follow suit.)

The reason that alert dialogs are modal is because they're critical to
the stability of the browser. The user needs to interact with them
very soon, otherwise any other site/page/window/tab that interacts
with that window should be "hung" by the run to completion promise
from the beginning of javascript.

Now, it's true that the dialog isn't app modal, but that's a
compromise that added complexity.

> Here's a strawman (which I'm sure has some subtleties I've not considered):

write a browser impl first and get back to us.