Background: Javascript programs use a single-threaded paradigm, and alert/prompt/confirm functions are synchronous (they block javascript execution until they return). This means that once the modal dialog pops open, nothing else in that javascript environment should be allowed to execute. If you violated this, you would have race conditions which the javascript program does not expect, and undefined behavior could happen.
Goal: Make alerts less annoying by reducing their scope from application modal to tab-modal. Problems: There is not necessarily a 1:1 mapping between javascript environments and tabs/windows. For example, popup windows, and the tab which spawned them share the same environment. So if either the tab or one of its popups calls alert(), ALL of those windows must be suspended, and block on the modal dialog. This gets hairier when you consider renderer process boundaries. Unlike other browsers, chrome (mostly) has tabs running in separate processes, which means they have their own thread and js environment. This isn't the whole story though, for a number of reasons pages may run in the same renderer process. This means they share the same javascript thread, and when any one of them blocks, the others will be blocked too. So while you only want to block Tab1 and popup1 when an alert happens, you may end up having to block Tab2, Tab3, Tab4 as well! (and communicating to the user why this other stuff is blocked too, can easily become confusing). Note even when tabs are not in the same renderer, there are still UI challenges in conveying a set of windows blocked by a modal dialog. (Since it may be the tab has some children popups). You now need to associate the dialog with a set of windows, and make it clear why they are blocked, and which window an alert originates from (security concern). Plugins also need to be able to do alerts, and expect it to all work synchronously. Lastly, tere are some compatibility considerations (arguably minor, but still need to consider) Some applications use alerts as a form of notification. (lack of a notification system is another of my pet peeves, but that is a different story). For example, Google Calendar will trigger an alert when a meeting is 10 minutes away. Many people keep Calendar open in a background tab, and rely on behavior that the alert will be sent to the foreground and interrupt whatever else they are doing. On Sun, Sep 7, 2008 at 3:39 PM, Bernd Kreuss <[EMAIL PROTECTED]>wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > deanm wrote: > > There are just a lot of complex > > technical hurdles to getting non-modal alert dialog boxes. > > They must *not* be non-modal. They must be Tab-modal and not > Browser-modal and only drawn when the tab is visible. This is no problem > at all to implement, a handfull lines of code and a maximum of two hours > for implementing and testing for someone who is familar with the code. > Absolutely no problem. The most complex part in this would probably be > the graphical design of the alert icon and its animation in the alerting > tab. > > > > - -- > private communication within hostile networks: > http://torchat.googlecode.com/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIxFgcxT6R4jlFoh0RAjx0AKDfP58CJowZwMQFHHXeA+ZuvupVYgCfUa1o > 93LjVTcV7OiAqI/lngwEiRQ= > =GL6N > -----END PGP SIGNATURE----- > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
