An async menu might be an option for WinChromium but it isn't an option for the Mac version if we want to use system menus. (And no, that wasn't an opening for anyone to say that we shouldn't use the system menus on the Mac...)
Avi On Mon, Mar 9, 2009 at 4:31 PM, Adam Barth <[email protected]> wrote: > I think we should show the menu asynchronously after roundtripping the > renderer to get the necessary state. We can solve the hung renderer > problem with a timeout. I like the idea of a "kill page" menu if the > page doesn't respond in time because the page menu is mostly useless > if the page is hung. > > Adam > > > On Mon, Mar 9, 2009 at 2:19 PM, <[email protected]> wrote: > > 1) the user right clicks on the page > > 2) the browser sends an IPC to the renderer with the click event > > 3) the renderer realizes that a context menu should show and sends > > an IPC back to the browser with information about which menu items > > should be enabled. > > > > In theory, this is the same as sending an IPC when we show the page > > menu, but the main differences is that the context menu ipcs are all > > async. > > > > You could imagine that we enable cut/copy/paste as we show the page menu, > > send an async request to see if the menu items should be enabled, and > > update the menu items async. This might flicker sometimes, but maybe > > that's ok? Alternately, we could delay showing the page menu until the > > page responds (like how context menus work). However, a hung/slow page > > would cause the menu to never appear, but maybe that's ok because all the > > menu items depend on the page anyway (if it hangs, we could replace the > > menu with a "kill tab" menu item). > > > > > > > > On Mon, 9 Mar 2009, Adam Barth wrote: > > > >> > >> The context menu does some kind of hit test on the renderer and gets > >> back info about what's under the mouse. I think the IPC message that > >> comes back from the renderer knows whether cut/copy/paste should be > >> enabled. I guess that's evidence that round-tripping through the > >> renderer to get this state might not be that bad for the page menu. > >> > >> Adam > >> > >> > >> On Mon, Mar 9, 2009 at 1:14 PM, Avi Drissman <[email protected]> wrote: > >> > Oh, that's curious. Where does the context menu come from? And how > does it > >> > know? > >> > > >> > Avi > >> > > >> > On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth <[email protected]> wrote: > >> >> > >> >> Thanks. I always use our context menu, which seems to be smarter > >> >> about disabling cut/copy/paste. > >> >> > >> >> Adam > >> >> > >> >> > >> >> On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin <[email protected]> > wrote: > >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth <[email protected]> > wrote: > >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman <[email protected]> > wrote: > >> >> >>> For those unfamiliar, the copy/paste menu items are always > enabled, > >> >> >>> and send > >> >> >>> a message to TabContents. > >> >> >> > >> >> >> Do you have an example of how to reproduce this issue? On > Windows, > >> >> >> the Cut/Copy/Paste menu items are often disabled when they won't > work. > >> >> > > >> >> > 1) Change your sound scheme to "Windows default". > >> >> > 2) Make sure no text is selected in Chrome. > >> >> > 3) Page menu -> copy. Beep! Also beeps if you hit ctl-c while > typing. > >> >> > > >> > > >> > > >> > >> > >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
