Provide toplevel window to plugins for WM_TRANSIENT_FOR of dialog boxes

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: karlt, Assigned: karlt)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

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.
Attachment #269336 - Flags: superreview?(roc)
Attachment #269336 - Flags: review?(roc)
Attachment #269336 - Flags: review?(jst)
The dependency on bug 384845 is for gdk headers in nsObjectFrame.cpp.
Depends on: 384845
Attachment #269336 - Attachment is patch: true
Attachment #269336 - Attachment mime type: text/x-patch → text/plain
Attachment #269336 - Flags: superreview?(roc)
Attachment #269336 - Flags: review?(roc)
Attachment #269336 - Flags: review?(jst)
Attachment #269336 - Attachment is obsolete: true
Attachment #269340 - Flags: superreview?(roc)
Attachment #269340 - Flags: review?(roc)
Attachment #269340 - Flags: review?(jst)
Attachment #269340 - Flags: superreview?(roc)
Attachment #269340 - Flags: review?(roc)
Attachment #269340 - Flags: review?(jst)
This one I have tested :-/
Attachment #269342 - Flags: superreview?(roc)
Attachment #269342 - Flags: review?(roc)
Attachment #269342 - Flags: review?(jst)
Attachment #269340 - Attachment is obsolete: true
Attachment #269342 - Flags: superreview?(roc)
Attachment #269342 - Flags: superreview+
Attachment #269342 - Flags: review?(roc)
Attachment #269342 - Flags: review+
Attachment #269342 - Flags: review?(jst) → review+
Checked those in.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.