Ah, very interesting. I had not paid attention to gtk2xtbin.c when blizzard added that back in '02. Originally, people just managed all of the X level stuff manually for plugins. I agree that we should do like Mozilla and use GtkSocket.
-Darin On Fri, Feb 13, 2009 at 1:34 AM, Dean McNamee <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
