This could potentially change in response to DOM mutations... Maybe send the state back on every input event ack? I'm not sure how much that will hurt performance.
Adam On Mon, Mar 9, 2009 at 2:58 PM, Avi Drissman <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
