On Thu, Dec 18, 2008 at 11:04 AM, Charles Reis <[email protected]> wrote:
> 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 think all dialogs can be canceled because they have a close button in the dialog frame, so we'd just auto-close them if they originate from a background tab. This seems sensible since the tab is not in the foreground. It might also make sense to only allow the foreground tab in the foreground window to generate an alert, confirm, prompt or showModalDialog call. For other tabs, we could use presentation like an infobar or something like the blocked popup treatment. We could also incorporate a "this tab needs attention" UI either in the form of flashing the tab (like the windows task bar does) or via some other means. > > > 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? > Yes, I don't see how the UI for a seemingly random set of tabs being blocked by a dialog in one tab could be done in a reasonable fashion. It seems like it would be really confusing UI :-) -Darin > 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 -~----------~----~----~----~------~----~------~--~---
