When plugins create dialog boxes on X11 they should set the WM_TRANSIENT_FOR property to the appropriate toplevel Mozilla window. http://tronche.com/gui/x/icccm/sec-4.html: "The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID of another top-level window. The implication is that this window is a pop-up on behalf of the named window, and window managers may decide not to decorate transient windows or may treat them differently in other ways. In particular, window managers should present newly mapped WM_TRANSIENT_FOR windows without requiring any user interaction, even if mapping top-level windows normally does require interaction. Dialogue boxes, for example, are an example of windows that should have WM_TRANSIENT_FOR set." I propose using NPNVnetscapeWindow in NPN_GetValue to provide this information to plugins. Currently NPN_GetValue only returns a value for NPNVnetscapeWindow on XP_WIN || XP_OS2. The documentation is a little unclear. The literal description "native window on which plug-in drawing occurs" suggests the innermost (child) native window enclosing the plugin (although in fact the plug-in does not draw to a native window). However the context is for use in creating dialog boxes, and so the toplevel window would be more suitable. http://developer.mozilla.org/en/docs/NPN_GetValue: "MS Windows You can use this method to help create a menu or dialog box for a windowless plug-in. In order to bring up popup menus and modal dialogs, a plug-in needs a parent window. A windowless plug-in does not receive its own native window. Instead, it draws directly into the drawable given to it. Use the NPNVnetscapeWindow value to get the native window on which plug-in drawing occurs." The section "Creating Pop-up Menus and Dialog Boxes" of http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference:Drawing_and_Event_Handling also refers to NPNVnetscapeWindow. At one stage with XP_WIN, Mozilla's implementation of NPNVnetscapeWindow for XP_WIN provided the document (child) window. This was changed in Bug 271442 to be the innermost (child) window enclosing the plugin so that mouse coordinates could be interpreted. Bug 384975 provides X11 mouse event coordinates wrt the plugin rectangle, so X11 does not have the same need for the innermost window. The innermost enclosing window and the plugins location wrt that window may be useful for other purposes (such as one way to determine the position of the plugin wrt the screen or in creating native widgets :-/) but this window could be provided by other means such as XReparentEvent and/or XConfigureEvent or XConfigureRequestEvent events. Currently windowed plugins on X11 only have a child window id. Using this for the WM_TRANSIENT_FOR property appears to work with some window managers (kwin and reportedly metacity) that trace the specified child window to a known toplevel window, but this behaviour is not in the ICCCM documentation. (Windowless plugins on X11 would not have this window id.) Although it may sometimes be possible for plugins to trace the toplevel window from a child window using XQueryTree if they assume that the toplevel window's parent is the root window, this would be inconvenient for the plugin and the assumption that toplevel windows are direct children of the root window is not valid for all window managers (See 4.2.1 Reparenting in http://tronche.com/gui/x/icccm/sec-4.html). The toplevel window is what plugin authors are most likely to need and so I suggest using NPNVnetscapeWindow to provide this.

roc, I'm asking you to review the code (because its in layout). jst, I'm asking you to confirm that you're happy with using NPNVnetscapeWindow to provide the toplevel window.

The dependency on bug 384845 is for gdk headers in nsObjectFrame.cpp.

This one I have tested :-/

Checked those in.