Sorry to jump in late here, but I can contribute a few thoughts. (For those interested, I've been working on how pages are divided into different renderer processes / tab groups.) First, Darin's right that some groups of pages would have to be suspended together, since they can access each other on a single JavaScript thread. The groups are based both on which tabs have connections to each other (like when Google Docs opens a new window for a document) and which pages are from the same domain. We call this a "site instance"-- all the connected pages from the same web site that could access each other.
(For more background on this than you probably need, see http://dev.chromium.org/developers/design-documents/process-models .) We're doing our best to put pages from different site instances in different renderer processes. From that standpoint, I think it might be perfectly reasonable to have a modal dialog specific to the renderer process. That would let you keep using the rest of the browser and any tabs in other renderer processes while the pages in a particular renderer process (i.e., site instance) are frozen behind a modal dialog. That would solve Marc-Antoine's use case with Gmail and Calendar. The two hiccups are choosing the right UI and dealing with Flash (or other plugins). For the UI, I'm not entirely opposed to the "OSX sheet" and tab dimming that Brian suggested, along with dimming other tabs in the same renderer process with a message along the lines of Sverrir's suggestion (with a link to bring up the tab they're waiting for). We could also try to shade or mark the relevant tabs in the tab strip when a dialog is shown. (IE8 actually colors the tabs of related tab groups, though I'm not a huge fan of this.) I'm not a UI expert here, though. The problem with the auto-cancel alert idea is that it doesn't work as well for modal dialogs that need a response (either yes/no or entering a value). Maybe they're not as common, but we'd have to deal with them. (Actually, I think there should be a different mechanism than alert for pages like Google Calendar to use, which would create a taskbar toast like Peter suggests. Specifically, it would be non-modal.) I don't have a great answer for Flash and plug-ins. I'd love to have a plug-in instance per renderer process, so that a Flash crash in one tab doesn't take down Flash in other tabs. That would avoid any problems with modal dialogs, too. But we'd also be introducing lots of memory overhead to do so, especially since so many pages have Flash ads. Besides, I think we probably have some race conditions between JS and Flash code already, since Flash is living in its own process. Probably worth discussing separately. Anyone see problems with a renderer-process-modal dialog? Charlie On Thu, Dec 18, 2008 at 3:12 AM, Sverrir Á. Berg <[email protected]> wrote: > >> I don't think this is the case for Flash. I think the expectation is >> if flash do ShowAlert(), no other javascript should be running while >> it's in ShowAlert(). That means we could make ShowAlert() return >> right away and not show any dialog, but if we did want to show a >> dialog (which we do), then we need to make ShowAlert() block while the >> dialog is visible, and we have to prevent any other javascript from >> running. >> > > OK I see - thanks. This would mean though that we could continue to run > javascript in any page groups that don't run Flash? And for all others > display the page modal dialog: Page XYZ is waiting for input as previously > suggested? > > Sverrir > > >> > >> > Sverrir >> > >> > >> > On Wed, Dec 17, 2008 at 10:36 AM, Marc-Antoine Ruel < >> [email protected]> >> > wrote: >> >> >> >> On Tue, Dec 16, 2008 at 7:32 PM, Brian Ellis <[email protected]> >> >> wrote: >> >> > >> >> > I may be repeating what Peter said to some extent, but unless I'm >> >> > missing something (and I may well be), the browser's security model >> >> > should prevent pages from referring to each other via JavaScript >> >> > across domain boundaries... so if the "page-modal" dialog also >> >> > "locked" all other tabs in the same tab group (which, as I understand >> >> > it, is defined as those tabs which share a domain) by graying out the >> >> > tab or otherwise indicating that it's unavailable, we could get 95% >> of >> >> > the way there with 5% of the headaches. It would be awesome if we >> >> > could perform some kind of analysis to determine that certain tabs >> are >> >> > independent of the locked page and not gray out those, but that seems >> >> > like a lot of work for not much extra benefit. The main thing here >> is >> >> > that user should not have to respond to the alert before they're >> >> > allowed to look at another page on a completely different domain; >> >> > anything that gets us that is, in my opinion, worth the time spent to >> >> > make it happen. >> >> >> >> My disruptive use case: >> >> - Open calendar, move the browser window on a second monitor, bury it >> >> under a lot of more important windows. >> >> - Open gmail on the primary monitor, chat with someone from gmail, >> >> extract the chat window. >> >> - Wait for a calendar alert. >> >> >> >> This stops me from entering text in my talk window and there is >> >> nothing that alerts me the reason of why this is happening. It reminds >> >> me cooperative multitasking. :( >> >> >> >> M-A >> >> >> >> >> > >> > >> > > >> > >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
