And that's the question, isn't it? :) What does affect the availability of copy/paste? I'll be looking into that soon.
avi On Mon, Mar 9, 2009 at 5:00 PM, Adam Barth <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
