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
On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman a...@google.com 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
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
On Wed, Mar 11, 2009 at 10:01 AM, Avi Drissman a...@google.com 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
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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
On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker ama...@chromium.org wrote:
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org 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,
I'm not trying to turn this into a huge deal. I've already filed a
bughttp://crbug.com/8662and 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
On Mon, Mar 9, 2009 at 10:12 AM, Avi Drissman a...@google.com wrote:
On Mon, Mar 9, 2009 at 12:02 PM, Evan Martin e...@chromium.org 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
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 aba...@google.com 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,
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 aba...@chromium.org
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
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 a...@google.com wrote:
An async menu might be an option for
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
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 ama...@chromium.org wrote:
Because we
15 matches
Mail list logo
