On Wed, Feb 11, 2009 at 6:51 AM, Dean McNamee <de...@chromium.org> wrote:
> In some of these cases, we are probably just using the HWND out of
> convenience so we don't have to keep state.

Yes--we also in some cases use the HWND's "user data" to hang state
off of so that we don't have to track it over the window's lifetime.
test_shell, for example, originally used this to associate an instance
of TestShell with a window (which I replaced with a map when we
brought it up on the Mac).

> I'm thinking maybe the best solution is along the lines of Adam's
> idea.  Basically some opaque 64-bit (or bigger) ID that we can pass to
> the renderer and have it pass back.  This ID will encapsulate a
> NativeViewId, along with security privileges.  This could be
> implemented all in the ID, along with an HMAC to make sure it's not
> tampered with.  It could also be an ID into a state table, much like
> how securable HANDLE objects work on Windows.  The HMAC implementation
> is probably the easiest.
>
> I have no idea what the situation is like on Mac.

The situation on the Mac is very similar to what you've described for
Gtk.  There is a system-wide window ID for each window, but it's not
visible or usable to most APIs;  the most useful native window
reference is a per-process object pointer.  I like the idea of
wrapping an index/ID in an opaque wrapper that can be passed back and
forth over IPC, though I also don't mind the idea of tracking state on
the browser side to make tamper detection easier or even moot.  It
seems like there would be very few places where the browser would need
the renderer to track a window reference.

> This is going to effect us immediately, as we're pulling up
> multiprocess Linux.  So I think it should be a priority to figure this
> out soon.

Same for the Mac, so agreed.

--Amanda

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

Reply via email to