[chromium-dev] Re: Thoughts on copy/paste

[Evan Martin]

On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  wrote:
> Working through crbug.com/8384 (copy/paste), I've had a chance to look at
> Chromium's current copy/paste system.
>
> For those unfamiliar, the copy/paste menu items are always enabled, and send
> a message to TabContents. WebContents implements those methods by forwarding
> them to RenderViewHost, which forwards them over IPC to the RenderView,
> which sends them to the focused WebFrame. He sends it to his Editor (finally
> in WebCore).

There's another bug in this space: webkit actually beeps if you send
it the "copy" message when you shouldn't have.  (I tracked this down
when I was looking into why it has a cross-platform portability layer
for beeping.  We didn't implement on Linux because beeping is NEVER
OK, and also disallowed by the sandbox.)  At least on Windows, no
other app beeps when there is no selection -- I think nobody noticed
this because the first thing you always do when setting up a new
Windows box is turn off the beeping.  :)

http://code.google.com/p/chromium/issues/detail?id=3508

(However, that bug could also perhaps be fixed by a smaller change
than what you propose.)

> Having menu items always selected is workable but rather gauche. And in
> fact, Editor has canCopy(), canPaste(), and a million other can* methods.
> And reverse-piping it through WebFrame is easy, but it starts getting sticky
> once you hit IPC.
>
> The problem is that we need to update the menu items when asked, which will
> be when the user pulls down the menu. Issue #1 is latency, just all those
> round trips over IPC. We could always do a state getting message, where the
> results of can* are all coalesced. But the bigger issue #2 is blocking, and
> locking up the UI if the renderer isn't responding/fast.

Yes, we don't want the UI to wait for the renderer ever.

Maybe a better option is to have the renderer send "FYI,
cut/copy/paste state is now x/y/z" messages up to the UI whenever it
changes?  (I guess paste is out of webkit's hands, but I can imagine
other booleans like whether "select all" should be enabled.)

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

On Mon, Mar 9, 2009 at 12:02 PM, Evan Martin  wrote:

> Maybe a better option is to have the renderer send "FYI,
> cut/copy/paste state is now x/y/z" messages up to the UI whenever it
> changes?  (I guess paste is out of webkit's hands, but I can imagine
> other booleans like whether "select all" should be enabled.)
>

That would make sense, but right now WebCore is set up for the UI to poll
rather than push updates. I suppose that glue could know when the state
might change, poll WebCore, and push updates, but that's a bit ugly. (Still
investigating...)

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Ojan Vafai]

On Mon, Mar 9, 2009 at 10:12 AM, Avi Drissman  wrote:

> On Mon, Mar 9, 2009 at 12:02 PM, Evan Martin  wrote:
>
>> Maybe a better option is to have the renderer send "FYI,
>> cut/copy/paste state is now x/y/z" messages up to the UI whenever it
>> changes?  (I guess paste is out of webkit's hands, but I can imagine
>> other booleans like whether "select all" should be enabled.)
>>
>
> That would make sense, but right now WebCore is set up for the UI to poll
> rather than push updates. I suppose that glue could know when the state
> might change, poll WebCore, and push updates, but that's a bit ugly. (Still
> investigating...)
>

Would changing this be a significant code change? WebKit folk might just be
OK with changing it to be push-based.


>
> Avi
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Adam Barth]

On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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.

Adam

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Evan Martin]

On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth  wrote:
> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

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  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  wrote:
> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth  wrote:
> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Adam Barth]

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  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  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  wrote:
>> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth  wrote:
>> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

I'll have to look at that; thanks.

In the meanwhile I've come to the unpleasant discovery that
ViewHostMsg_ClipboardIsFormatAvailable requires that Clipboard::FormatType
be IPC serializable. Time to hack at the Clipboard class.

Avi

On Mon, Mar 9, 2009 at 3:29 PM, 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  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  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  wrote:
> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth 
> wrote:
> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[tony]

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  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  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  wrote:
> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth  wrote:
> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Adam Barth]

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,   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  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  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  wrote:
>> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth  wrote:
>> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

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  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,   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  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  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 
> wrote:
> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth 
> wrote:
> >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman 
> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Adam Barth]

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  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  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,   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  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  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 
>> >> >> wrote:
>> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth 
>> >> >> > wrote:
>> >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman 
>> >> >> >> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Amanda Walker]

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  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  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  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,   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  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  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 
>>> >> >> wrote:
>>> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth 
>>> >> >> > wrote:
>>> >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman 
>>> >> >> >> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

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  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  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  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  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,   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 
> 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 
> 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 
> >>> >> >> wrote:
> >>> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth <
> aba...@chromium.org>
> >>> >> >> > wrote:
> >>> >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman 
> >>> >> >> >> 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: chromium-dev@googlegrou

[chromium-dev] Re: Thoughts on copy/paste

[Adam Barth]

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  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  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  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  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  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,   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 
>> >>> >> 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 
>> >>> >> > 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 
>> >>> >> >> wrote:
>> >>> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth
>> >>> >> >> > 
>> >>> >> >> > wrote:
>> >>> >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman 
>> >>> >> >> >> 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
>> >>> >> >> >> wo

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

[repost; went off-list]

We're not in control of it. We declare our menus, and when one is clicked
the system calls us back to update the enabled/disabled state of the items.
We return either true or false, and until we do the UI blocks.

This is different from right click menu. You right click, but while the
message is winding its way to the renderer (which might take a while or be
ignored entirely) the UI is still going.

Avi

On Mon, Mar 9, 2009 at 4:48 PM, Adam Barth  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  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  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,   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  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 
> 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 
> >> >> >> wrote:
> >> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth <
> aba...@chromium.org>
> >> >> >> > wrote:
> >> >> >> >> On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman 
> >> >> >> >> 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: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

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  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  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 
> 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  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  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 
> 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,   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 
> >> >>> >> 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 
> >> >>> >> > 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 <
> e...@chromium.org>
> >> >>> >> >> wrote:
> >> >>> >> >> > On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth
> >> >>> >> >> > 
> >> >>> >> >> >

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

I actually don't know. It seems like just simple state gathering but it
might be more.

The big concern is that it fits our model but no one else's. Everyone else
is OK with the UI asking the renderer questions directly, and as that's more
efficient than doing status updates that are going to be ignored 99.44% of
the time, I'm not sure they have incentive.

I need to land my first pass at copy/paste and then I'll be looking into
this exact question.

Avi

On Mon, Mar 9, 2009 at 1:28 PM, Ojan Vafai  wrote:

> On Mon, Mar 9, 2009 at 10:12 AM, Avi Drissman  wrote:
>
>> On Mon, Mar 9, 2009 at 12:02 PM, Evan Martin  wrote:
>>
>>> Maybe a better option is to have the renderer send "FYI,
>>> cut/copy/paste state is now x/y/z" messages up to the UI whenever it
>>> changes?  (I guess paste is out of webkit's hands, but I can imagine
>>> other booleans like whether "select all" should be enabled.)
>>>
>>
>> That would make sense, but right now WebCore is set up for the UI to poll
>> rather than push updates. I suppose that glue could know when the state
>> might change, poll WebCore, and push updates, but that's a bit ugly. (Still
>> investigating...)
>>
>
> Would changing this be a significant code change? WebKit folk might just be
> OK with changing it to be push-based.
>
>
>>
>> Avi
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Adam Barth]

On Tue, Mar 10, 2009 at 7:47 AM, Avi Drissman  wrote:
> And that's the question, isn't it? :) What does affect the availability of
> copy/paste? I'll be looking into that soon.

Yep.  :)

In principle, almost anything can affect the copy/paste state because
most things can run script and script can mutate the DOM, which can
change the copy/paste state...

Adam

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Brett Wilson]

On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman  wrote:
> I actually don't know. It seems like just simple state gathering but it
> might be more.
>
> The big concern is that it fits our model but no one else's. Everyone else
> is OK with the UI asking the renderer questions directly, and as that's more
> efficient than doing status updates that are going to be ignored 99.44% of
> the time, I'm not sure they have incentive.

I'm not sure what you mean by this. What is everyone OK with?

Brett

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

Most platforms (meaning not Chrome) have the ability, when the user pulls
down a menu, to adjust the states of the menu items within. For them, when
the user selects the Edit menu, they're OK calling into WebCore and asking
the Editor canCopy(), canPaste(), etc.

We're pretty much the only ones decoupling the UI from WebCore to the extent
that we disallow blocking. With that design, we're forced to have WebCore
(or at least glue/) bubble up state changes. Compared to just asking WebCore
at the time of need, having state change notifications is more inefficient.
I think it's worth paying the price. But it might be a harder sell to
upstream.

Avi

On Wed, Mar 11, 2009 at 1:21 PM, Brett Wilson  wrote:

> On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman  wrote:
> > I actually don't know. It seems like just simple state gathering but it
> > might be more.
> >
> > The big concern is that it fits our model but no one else's. Everyone
> else
> > is OK with the UI asking the renderer questions directly, and as that's
> more
> > efficient than doing status updates that are going to be ignored 99.44%
> of
> > the time, I'm not sure they have incentive.
>
> I'm not sure what you mean by this. What is everyone OK with?
>
> Brett
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Brett Wilson]

On Wed, Mar 11, 2009 at 10:01 AM, Avi Drissman  wrote:
> Most platforms (meaning not Chrome) have the ability, when the user pulls
> down a menu, to adjust the states of the menu items within. For them, when
> the user selects the Edit menu, they're OK calling into WebCore and asking
> the Editor canCopy(), canPaste(), etc.

Do you mean when you click on the menu, blocking the browser until the
renderer responds with whether the menus can be enabled? I would be
opposed to that.


> We're pretty much the only ones decoupling the UI from WebCore to the extent
> that we disallow blocking. With that design, we're forced to have WebCore
> (or at least glue/) bubble up state changes. Compared to just asking WebCore
> at the time of need, having state change notifications is more inefficient.
> I think it's worth paying the price. But it might be a harder sell to
> upstream.

State changes won't fix the problem either. There is no way in the
browser to know about the current state of the renderer without one or
the other one blocking. State change notifications don't address this
problem.

Brett

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Amanda Walker]

On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson  wrote:
> Do you mean when you click on the menu, blocking the browser until the
> renderer responds with whether the menus can be enabled? I would be
> opposed to that.

So are we, but that's what WebKit currently assumes.  That's why we've
been trying to brainstorm a way around it.

--Amanda

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Brett Wilson]

On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker  wrote:
> On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson  wrote:
>> Do you mean when you click on the menu, blocking the browser until the
>> renderer responds with whether the menus can be enabled? I would be
>> opposed to that.
>
> So are we, but that's what WebKit currently assumes.  That's why we've
> been trying to brainstorm a way around it.

This seems like it is not worth worrying about until the mac browser
is as good as the Windows one. We have this "bug" on Windows, and it's
not held anything up so far.

Brett

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson  wrote:

> Do you mean when you click on the menu, blocking the browser until the
> renderer responds with whether the menus can be enabled? I would be
> opposed to that.
>

Right, that would be bad for us. But for most users of WebCore, such a thing
would be fine (since, without process separation, there's a million ways for
the renderer to hose the browser, and this is the least of their concerns).


> State changes won't fix the problem either. There is no way in the
> browser to know about the current state of the renderer without one or
> the other one blocking. State change notifications don't address this
> problem.


I fail to see your problem. The renderer sends notifications about its
state, and the browser uses the last (cached) value to present its menus as
correctly as it can to the user.

Avi

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Avi Drissman]

I'm not trying to turn this into a huge deal. I've already filed a
bugand am likely to move on for now. But for me
it's just another issue that
users are going to complain about that I'm going to need to fix someday.

Avi
/who bets the first complaint will be from a Mac user rather than a Windows
one

On Wed, Mar 11, 2009 at 2:12 PM, Brett Wilson  wrote:

> On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker 
> wrote:
> > On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson 
> wrote:
> >> Do you mean when you click on the menu, blocking the browser until the
> >> renderer responds with whether the menus can be enabled? I would be
> >> opposed to that.
> >
> > So are we, but that's what WebKit currently assumes.  That's why we've
> > been trying to brainstorm a way around it.
>
> This seems like it is not worth worrying about until the mac browser
> is as good as the Windows one. We have this "bug" on Windows, and it's
> not held anything up so far.
>
> Brett
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Thoughts on copy/paste

[Darin Fisher]

I added a comment to the bug describing how we have solved problems like
this in the past.
-Darin


On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman  wrote:

> Working through crbug.com/8384 (copy/paste), I've had a chance to look at
> Chromium's current copy/paste system.
>
> For those unfamiliar, the copy/paste menu items are always enabled, and
> send a message to TabContents. WebContents implements those methods by
> forwarding them to RenderViewHost, which forwards them over IPC to the
> RenderView, which sends them to the focused WebFrame. He sends it to his
> Editor (finally in WebCore).
>
> Having menu items always selected is workable but rather gauche. And in
> fact, Editor has canCopy(), canPaste(), and a million other can* methods.
> And reverse-piping it through WebFrame is easy, but it starts getting sticky
> once you hit IPC.
>
> The problem is that we need to update the menu items when asked, which will
> be when the user pulls down the menu. Issue #1 is latency, just all those
> round trips over IPC. We could always do a state getting message, where the
> results of can* are all coalesced. But the bigger issue #2 is blocking, and
> locking up the UI if the renderer isn't responding/fast.
>
> This feels like it should be a solved problem. Any suggestions as to where
> to look?
>
> Avi
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---