Hey Darin,
The long story is pretty long, but I can explain it if you're
interested in all of the details. The medium sized version:
Gtk implements a non-trivial amount of code for handling the X event
forwarding and management of the xembed protocol, which is how modern
plugin embedding on Linux works. In order to take advantage of this
code, we need a GtkWidget (in this case a GtkSocket) in the Gtk
hierarchy. If we were to do things like move the backing X window
directly (without asking Gtk to move it), Gtk is just going to "move
it back" on the next layout, since Gtk is managing its position.
Evan had originally implemented a custom container widget that prevent
Gtk from laying out the plugin windows. However, it turned out layout
is an important step, as the GtkSocket uses these events to send an
expose message to the plugin. There is a balance here, the more we
start trying to sidestep how Gtk wants things to be done, the more
we're skipping over important code thats required and expected by the
embedded plugins.
I have a strategy that I think will work for plugins. It will mean
that the window can be create and managed from only the same process.
If the renderer needs to tell the browser to move a window, we need to
move the GtkWidget, and not the X window. We can't work in X window
IDs here, we need the GtkWidget* so we can move it within its parent
container. We could put the X id in a map, and pull out the
GtkWidget*, but then the id is arbitrary. We could also iterate over
all of the plugin windows, asking for their X window id until it
matches, that's an O(n) search which would probably be ok, but it's
not very elegant.
I believe the situation is similar on the Mac. I'm not sure the
current design of passing HWNDs between processes conceptually extends
beyond win32.
My impression so far from a handful of conversions is there isn't a
big willingness to change here. If that's the case, we will just have
to come up with some hacks that allows the win32 design work on the
other platforms.
Thanks
-- dean
On Fri, Feb 13, 2009 at 4:08 AM, Darin Fisher <da...@chromium.org> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
