Forgive my ignorance of Mac APIs, but why does the mouse click -> display menu need to be synchronous? (In a way similar to how the right-click -> context menu is async now.)
Adam On Mon, Mar 9, 2009 at 2:39 PM, Avi Drissman <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
