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 <a...@google.com> 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
-~----------~----~----~----~------~----~------~--~---
