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 -~----------~----~----~----~------~----~------~--~---
