This sounds nice and simple on the surface.... I spent a lot of energy trying to figure out how to make it fly to no avail. Short version:
The problem is that no matter how you cut it, you end up violating the run-to-completion (non-reentrant) constraint of javascript. It is not enough to prevent the script on the page that calls alert from executing javascript again. You also have to worry about other pages that may be able to script the page that is currently calling alert. So, you could have multiple tabs that are all able to script one another. In fact, it could be tab A calling alert on the window object of tab B. Those tabs could also be in different browser windows. If you think through those kinds of scenarios, you can imagine how this kind page-modal UI breaks down. This problem is further complicated by the fact that Flash can also cause script to execute in the web page, and all web pages use the same Flash process (same Flash thread even). The Flash process needs to also see the same kind of run-to-completion world. So, then all tabs running Flash (not just the ones in the same domain) are linked together in this way. Hence, the need for app-modal alerts. -Darin On Tue, Dec 16, 2008 at 3:13 PM, Brian Ellis <[email protected]> wrote: > > Hi folks, > > I wanted to share an idea that I think could substantially improve the > user experience of the various modal dialogs used in Chrome. You can > see it here: > > http://docs.google.com/Doc?id=dj6xpc2_0hspk5vcw > > For the tl;dr crowd, basically the idea is to introduce the concept of > a page-modal dialog. When a page-modal dialog in onscreen, the user > can't interact with the page that showed the dialog (for example > scrolling, clicking links, right-clicking on the page, etc.) but can > interact normally with everything else in the window -- he or she can > close the tab, switch to another tab, close the window, show the > Options dialog, etc. This makes the dialog modal from the point of > view of a script on the page (preserving the existing semantics of > functions like alert()), but avoids forcing the user to interact with > the dialog before they can do anything else in the browser, thwarting > DoS attacks and removing an attractive vehicle for "dialog spammers" > to claim the user's attention. See the doc for more details and > mockups. > > Brian > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
