After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 405269 - XLowerWindow() does not push a window with XA_WM_TRANSIENT_FOR set to back
XLowerWindow() does not push a window with XA_WM_TRANSIENT_FOR set to back
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2007-02-07 08:30 UTC by Anthony Petrov
Modified: 2020-11-06 20:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Anthony Petrov 2007-02-07 08:30:20 UTC
According to the Xlib specification, if the window is WM-managed, the XLowerWindow() function just sends ConfigureRequest event to the WM and "no further processing is performed".

I've got a test that creates three windows: 2 usual window (f1 and f2) and one window (d1) that has the XA_WM_TRANSIENT_FOR property set pointing to the f1 window (see the test code below). Clicking the client area of any of these windows invokes the XLowerWindow() function on that window. Clicking the f2 window does work correctly (the f2 window goes back). Clicking the d1 window does invokes the XLowerWindow() function, but no effect is visible (both f1 and d1 (above the f1 as a transient-for window) stay in the same z-order position not going back under the f2 window). It means that Metacity does not process the ConfigureRequest event properly for windows with XA_WM_TRANSIENT_FOR property set.

The behavior is observed with any Metacity version 2.x including the latest stable one (2.16). However, running the test under any other WM (notably the KWin of KDE) produces correct results (any clicked window goes back (and d1 also pushes the f1 back as well as a transient-for window) according to the XLowerWindow() specification).

The test code:


#include <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xos.h>
#include <X11/Xutil.h>

#include <stdio.h>

Display *display;
int screen_num;
Window root;

Window create_window(char * name, int x, int y, int width, int height) 
{
    XSizeHints sh;
    XWMHints wmh;
    Window win = XCreateSimpleWindow(display, root, x, y, width, height,
                                     2, // border width
                              BlackPixel(display, screen_num),
                              WhitePixel(display, screen_num));                 
    XStoreName(display, win, name);
    XSelectInput(display, win, ButtonPressMask | KeyPressMask);
    
    sh.width = width;
    sh.height = height;
    sh.x = x;
    sh.y = y;
    sh.flags = USPosition | USSize;
    XSetWMNormalHints(display, win, &sh);

    return win;
}

int main(int argc, char **argv)
{
  Window f1, f2, d1;
  XEvent ev;
  XButtonEvent bev;

  int i, k;

  char *display_name = NULL;
  if ((display = XOpenDisplay(display_name)) == NULL)
  {
    fprintf(stderr, "Couldn't open %s\n", XDisplayName(display_name));
    return -1;
  }
  screen_num = DefaultScreen(display);
  root = RootWindow(display, screen_num);

  f1 = create_window("Frame 1", 100, 100, 200, 200);
  XMapWindow(display, f1);

  f2 = create_window("Frame 2", 400, 100, 200, 200);
  XMapWindow(display, f2);

  d1 = create_window("Dialog 1", 200, 100, 150, 150);
  XMapWindow(display, d1);

  XFlush(display);
  XSync(display, False);

  XSetTransientForHint(display, d1, f1);

  XFlush(display);
  XSync(display, False);

  while (1)
  {
    XNextEvent(display, &ev);
    if (ev.type == ButtonPress)
    {
      bev = ev.xbutton;
      XLowerWindow(display, bev.window);
      XFlush(display);
      XSync(display, True);
    }
  }
}
Comment 1 Havoc Pennington 2007-02-07 14:57:51 UTC
To be clear, there is no specification-compliance issue here; the WM is allowed to do whatever it likes with a ConfigureRequest (that is the core definition of a WM, it overrides ConfigureRequest instead of allowing the X server to handle it in the normal way).

So the question is just what is the right behavior. I take it you want lowering the transient to lower both the transient and its parent, keeping the transient above the parent?

That sounds potentially OK, metacity just is not that clever right now. It will try to maintain the "transient above its parent" constraint while only moving the transient itself.
Comment 2 Anthony Petrov 2007-02-08 14:29:42 UTC
Well, actually you're correct. A WM is free to decide whether it does something or not. However, taking into account that KWin implemented the behavior already, and the behavior seems quite reasonable, I would like to see the same behavior running under Metacity as well.
Comment 3 Andrew John Hughes 2010-04-06 18:38:57 UTC
Any news on this?  It's still causing issues:

https://bugzilla.redhat.com/show_bug.cgi?id=577953
Comment 4 André Klapper 2020-11-06 20:09:35 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.