GNOME Bugzilla – Bug 322840
Synthetic ConfigureNotifys and MapRequest events
Last modified: 2017-03-18 16:40:03 UTC
Version details: reproduced with 2.10.3 Distribution/Version: 6.0-RELEASE, Linux, Solaris and others When a client places a window with PPosition or UPosition, Metacity does not send a synthetic ConfigureNotify to tell the client of it's new on screen position. Applications rely on this to be able to place windows at their last on screen position. This means that windows that are placed this way have a tendency to walk up the screen unless the user explicitly moves the window to a new location, or that the application doesn't have a chance to update it's internal state, and the windows are saved at some random location (however, this is often 0,0). There is currently no way to work around this.
This is probably a one-liner to fix -- just making sure to call send_configure_notify() at the right place; the trick is figuring out where to make that call and verifying that it's the right place. It'd be really helpful if someone could write a simple test program displaying this bug, to make it easier to test and verify. Anyway, once the test case is written, I'm pretty sure the relevant function is meta_window_move_resize_internal() (though you may need to dig around meta_window_place() too, which is called from meta_window_constrain() which is called in turn from meta_window_move_resize_internal()).
Created attachment 64447 [details] Testcase
The test case shows the bug quite easily for me. When I run it (metacity is running on display :1), I get: [bhughes@reticent] ~/src/xpos% DISPLAY=:1 ./xpos got MapNotify, last ConfigureNotify pos was 5,24 XTranslateCoordinates says pos is 105,124 Other window managers work, usually by delivering a synthetic ConfigureNotify before the MapNotify (in this case, blackbox): [bhughes@reticent] ~/src/xpos% ./xpos got synthetic ConfigureNotify before being mapped, pos 101,123 got synthetic ConfigureNotify before being mapped, pos 101,123 got MapNotify, last ConfigureNotify pos was 101,123 XTranslateCoordinates says pos is 101,123
Cool, thanks for the testcase. I decided to look and see if we were missing any other places where synthetic ConfigureNotify events should be sent, and found that it appears totally undefined whether they should be sent at all in response to MapRequest events. I emailed the wm-spec-list about this (http://mail.gnome.org/archives/wm-spec-list/2006-April/msg00045.html). I think it should probably be hammered out in the EWMH so that I can be certain we are getting it right (e.g. what about if UPosition and PPosition aren't set?)
Created attachment 69095 [details] Alternate Test Case ( i believe ) When a dialog is diaplayed there is a significant delay before it appears. The attached program demonstrates this. When run it shows a small dialog with a push button. Press the button and a dialog appears. Press it again and the dialog disappears and there is a 5 second delay before it appears. Move the dialog and press the button again, the dialog appears immediately. Also, With no window manager running, the dialog appears immediately My best guess is that the window manager is not responding with a synthetic configure notify event for the configure request when there is no change in position. Whether the window manager is non-conformant to the Inter-Client-Communications-Convention-Manual or Xt is expecting an event that it is not entitled to I don't know.
Created attachment 85829 [details] [review] Fix the bug Rationale for fix came from Dan: http://mail.gnome.org/archives/wm-spec-list/2006-May/thread.html See also http://mail.gnome.org/archives/wm-spec-list/2006-September/msg00019.html.
erm, the link to Dan's email should have been: http://mail.gnome.org/archives/wm-spec-list/2006-May/msg00000.html Anyway, I committed the patch to trunk, the gnome-2-18 branch, and the gnome-2-16 branch. The fix will be in metacity 2.16.x, with x>=8 metacity 2.18.x, with x>=1 metacity >= 2.19.1 metacity-2.16.8, metacity-2.18.1, and metacity 2.19.1 have all been released today so people can grab the new versions off ftp.gnome.org. metacity 2.19 is of course the development version and I don't know if any distributors will bother picking up any more 2.16 tarballs, but they are there just in case.
Bug present again in later versions. I've opened up Bug 582580.
As I mentioned in my previous comment, later versions are still broken. But it actually turns out that 2.16.8 is broken as well; it is NOT fixed as comment #7 says.