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
> 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
-~----------~----~----~----~------~----~------~--~---
