- From: timeless <timeless@gmail.com>
- Date: Sun, 14 Dec 2008 18:04:19 +0200
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.
Received on Sunday, 14 December 2008 08:04:19 UTC