Right. That involves some magic on the renderer side, probably polling WebCore for state after operations known to change it. Currently, WebCore isn't really set up for sending copy/paste state changes.
Avi On Mon, Mar 9, 2009 at 4:55 PM, Amanda Walker <[email protected]> wrote: > Because we don't see the mouse click for the main menu bar the same > way we do for a context menu. Normally, we just get called back after > a menu item has been selected. It's possible to update state while > the menu is down, but that brings in the possibility of flashing/etc. > as the menu changes state under the mouse, which is bad. If there's a > way that the browser process can shadow the "most recent clipboard > state" of the current renderer, that would be ideal. > > --Amanda > > > On Mon, Mar 9, 2009 at 5:48 PM, Adam Barth <[email protected]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
