I had assumed that NativeWindowID should just be the X window ID in our
Linux build. That is what NPAPI uses (see NPWindow), and so it is what we
will need to pass around.
I think you can initialize a GdkWindow from a X window ID. I don't think we
should worry about the case where GDK is not running on top of X :-)
It would probably take some considerable work to stop passing HWNDs / X
window IDs through the renderer on behalf of plugins.
-Darin
On Wed, Feb 11, 2009 at 6:51 AM, Dean McNamee <de...@chromium.org> wrote:
> On Windows, pretty much everything deals in HWNDs, which is an integer
> index into a kernel handle table. This means HWNDs, which are just
> integer window ids, are good across processes. The fact that all of
> the Windows APIs work in HWNDs, means that it is the primitive for
> NativeWindow and NativeView on Windows.
>
> On Linux, we have a similar concept, the X window id. However, our
> NativeWindow is currently a GtkWindow, and NativeView is a GtkWidget.
> Both a GtkWindow (this is the top level application window) and a
> GtkWidget can be backed by a GdkWindow, which encapsulates the X
> window id. Gtk is a cross-platform toolkit, which is one of the
> reasons you don't deal w/ the window ids directly.
>
> A recent example of this I've encountered is
> DidMove(WebPluginGeometry), which has a NativeView handle. This is
> not going to be IPC-able, as this would be a pointer to a GtkWidget
> instance, which obviously won't be good across processes. In order to
> have something that would be, we would need to do GtkWidget ->
> GdkWindow -> x window id. Then on the other side we'd have to create
> a new GdkWindow around the x window id.
>
> It seems we might need some new abstractions, since on Linux both
> NativeView and NativeWindow are pointers, not integers that are valid
> between processes. It seems like we need some NativeWindowId
> abstraction. Hey, I just looked at the code, I noticed someone added
> a NativeViewId type and conversion methods, so we already have the
> abstraction. We just need to start using them.
>
> I'm not sure this is enough security-wise though. It is scary to
> allow the to renderer send messages to the browser, telling it to do
> operations on arbitrary windows. I think this is where Adam mentioned
> something like HMAC, or we could do some sort of handle type thing to
> implement security. This might be a bit tricky, depending where the
> window is created an used (we have 3 processes involved, plugin,
> browser, and renderer). It would be nice if we could also enforce IDs
> per-renderer process, and not just HMAC'd to any renderer.
>
> In some of these cases, we are probably just using the HWND out of
> convenience so we don't have to keep state. It seems like it's
> probably a mess to try to duplicate the state in the browser process,
> but that's also one possible solution.
>
> 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.
>
> 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.
>
> Thanks
> -- dean
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
