GNOME Bugzilla – Bug 124667
not honoring PPosition on dialogs?
Last modified: 2006-04-28 20:28:26 UTC
i discovered some java(swing) apps (don't know if only java has this problem), that cause the WM to log following message: Window manager warning: Window 0x2e003c9 (Choose Imp) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense. in this case the window is a popup. it should be placed somewhere inside the parent window. but because of the senseless size, metacity replaces the window to the upper left corner. another java app has the same problem with (context)menus. it is a little annoying to open a (context)menu wich is not under the mouse but somewhere else on the screen ;) not all menus or popups have this problem. i think the reason is, that the windows in this case are dynamically sized. earlier versions of metacity didn't have that problem. currently i'm using the 0.27.1 garnome distribution with metacity 2.6.1.
the window placement has nothing to do with whether or not the window is resizable. The dialog gets placed using the normal placement algorithm because as best as metacity can determine, it's a normal, top-level window. The only solution is for the Java app to set the appropriate hint, unless you happen to know of a heuristic for determining this.
The problem here AFAIK is pretty simple: Java claims the popup menus are dialogs and uses managed windows for them. Popup menus _must_ be override redirect, or you can't implement grabbing and avoid nasty race conditions. Aside from the fact that dialogs get placed... I filed a bug with Sun about this probably a year or more ago. I'm not sure if the Java bug system lets you go back and look at any progress on it. That said, if the popup sets the PPosition flag it should not get repositioned. We should verify that it does not set this flag. One way is to run "METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 metacity --replace" on a system with no extraneous windows open; quickly open the popup window; then kill metacity and harvest the log file, and "Create a new attachment" here to attach the log file. You may also be able to use "xprop" to get the properties of the popup. Or both ;-) Reopening to verify we don't reposition things that set PPosition
it is definite, that 2.5.x didn't have the problem. so i'm sure metacity is doing something it didn't do before. to find out more details i'm building a swing-app now and will attach it the next few days for you to reproduce the misbehaviour. (and i will also attach my logs) please stand by on this.
Created attachment 21513 [details] ok, eventually i succeeded and found time to test this out. here is an app which produces the problems. start with java -jar swingtest.jar. compiled for java 1.4.1
Created attachment 21514 [details] logged a popup. it was positioned WRONG. interesting lines maybe: 2540, 2719, 2752
it really seems like PPosition is not honored. this is the broken popup logged with xprop: _NET_WM_DESKTOP(CARDINAL) = 5 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_ MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_CHANGE_DESKTOP _OL_DECOR_DEL(ATOM) = _OL_DECOR_HEADER, _OL_DECOR_RESIZE, _OL_DECOR_CLOSE WM_TRANSIENT_FOR(WINDOW): window id # 0x3000039 _MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET WM_PROTOCOLS(ATOM): protocols _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x2c, 0x0, 0xffffffff, 0x156 WM_CLIENT_LEADER(WINDOW): window id # 0x300000b WM_LOCALE_NAME(STRING) = "C" WM_CLASS(STRING) = "com.sun.java.swing.plaf.windows.WindowsPopupWindow", "com.stattmann.swing.FunkySwing" WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x3000039 WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 442, 348 program specified size: 227 by 44 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = "bollinger" WM_NAME(STRING) = " " i found out, that not only certain lookandfeels have this problem with a popup, but also normal dialog windows get positioned wrong. please try my small app here. the derived windows lf is ok in jdk 1.4.2, but dialog problems remain.
So, it first seems to get it right during initial window creation: GEOMETRY: Move/resize 0x300004e ( ) to 442,348 227x44 (configure request) from 442,348 227x44 GEOMETRY: Compensated position for gravity, new pos 442,348 GEOMETRY: Constraining 0x300004e ( ) x_move_delta = 0 y_move_delta = 0 x_direction = 2 y_direction = 2 x_delta = 0 y_delta = 0 orig 442,348 227x44 WORKAREA: Window 0x300004e ( ) xinerama 0 has work area 0,28 1600 x 1122 WORKAREA: Window 0x300004e ( ) has whole-screen work area 0,28 1600 x 1122 GEOMETRY: Before: 0 (Right constraint 'Desktop') GEOMETRY: After: 0 (Right constraint 'Desktop') GEOMETRY: Before: 0 (Right constraint 'Onscreen') GEOMETRY: After: 0 (Right constraint 'Onscreen') GEOMETRY: Before: 0 (Right constraint 'Hints') GEOMETRY: After: 0 (Right constraint 'Hints') GEOMETRY: Before: 0 (Bottom constraint 'Desktop') GEOMETRY: After: 0 (Bottom constraint 'Desktop') GEOMETRY: Before: 0 (Bottom constraint 'Onscreen') GEOMETRY: After: 0 (Bottom constraint 'Onscreen') GEOMETRY: Before: 0 (Bottom constraint 'Hints') GEOMETRY: After: 0 (Bottom constraint 'Hints') GEOMETRY: Before: 0 0 (Move constraint 'Desktop') GEOMETRY: After: 0 0 (Move constraint 'Desktop') GEOMETRY: Before: 0 0 (Move constraint 'Onscreen') GEOMETRY: After: 0 0 (Move constraint 'Onscreen') GEOMETRY: Before: 0 0 (Move constraint 'Hints') GEOMETRY: After: 0 0 (Move constraint 'Hints') GEOMETRY: Constrained 0x300004e ( ) new 442,348 227x44 old 442,348 227x44 Then when it clears the calc_showing_queue it screws it up: WINDOW_STATE: Clearing the calc_showing queue Window manager: Should be showing for window 0x300004e ( ) Window manager: Window 0x300004e ( ) is on the active workspace 5 Window manager: Implement showing = 1 for window 0x300004e ( ) WINDOW_STATE: Showing window 0x300004e ( ), shaded: 0 iconic: 0 placed: 0 GEOMETRY: Move/resize 0x300004e ( ) to 442,348 227x44 from 442,348 227x44 GEOMETRY: Constraining 0x300004e ( ) x_move_delta = 0 y_move_delta = 0 x_direction = 2 y_direction = 2 x_delta = 0 y_delta = 0 orig 442,348 227x44 WORKAREA: Window 0x300004e ( ) xinerama 0 has work area 0,28 1600 x 1122 WORKAREA: Window 0x300004e ( ) has whole-screen work area 0,28 1600 x 1122 PLACEMENT: Placing window 0x300004e ( ) XINERAMA: Natural xinerama 0 is 0,0 1600x1200 WORKAREA: Window 0x300004e ( ) xinerama 0 has work area 0,28 1600 x 1122 WORKAREA: Window 0x300004e ( ) xinerama 0 has work area 0,28 1600 x 1122 GEOMETRY: Before: -440 -306 (Move constraint 'Desktop') GEOMETRY: After: -440 -306 (Move constraint 'Desktop') GEOMETRY: Before: -440 -306 (Move constraint 'Onscreen') GEOMETRY: After: -440 -306 (Move constraint 'Onscreen') GEOMETRY: Before: -440 -306 (Move constraint 'Hints') GEOMETRY: After: -440 -306 (Move constraint 'Hints') GEOMETRY: Before: 0 (Right constraint 'Desktop') GEOMETRY: After: 0 (Right constraint 'Desktop') GEOMETRY: Before: 0 (Right constraint 'Onscreen') GEOMETRY: After: 0 (Right constraint 'Onscreen') GEOMETRY: Before: 0 (Right constraint 'Hints') GEOMETRY: After: 0 (Right constraint 'Hints') GEOMETRY: Before: 0 (Bottom constraint 'Desktop') GEOMETRY: After: 0 (Bottom constraint 'Desktop') GEOMETRY: Before: 0 (Bottom constraint 'Onscreen') GEOMETRY: After: 0 (Bottom constraint 'Onscreen') GEOMETRY: Before: 0 (Bottom constraint 'Hints') GEOMETRY: After: 0 (Bottom constraint 'Hints') GEOMETRY: Before: 0 0 (Move constraint 'Desktop') GEOMETRY: After: 0 0 (Move constraint 'Desktop') GEOMETRY: Before: 0 0 (Move constraint 'Onscreen') GEOMETRY: After: 0 0 (Move constraint 'Onscreen') GEOMETRY: Before: 0 0 (Move constraint 'Hints') GEOMETRY: After: 0 0 (Move constraint 'Hints') GEOMETRY: Constrained 0x300004e ( ) new 2,42 227x44 old 442,348 227x44 So it looks like it's actually a constraints related problem. Now, Kjartan bumped the GnomeVersion without giving a reason so I'm guessing it was in error. Could you verify whether this happens with a recent version of Metacity?
Looks like I forgot to mark this as NEEDINFO with my last comment.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. In particular, given that constraints.c has been rewritten at least once since you filed this bug (I don't recall when the first rewrite was so don't know if that was before or after), I'm going to go ahead and close and assume it's fixed. Thanks!
seems really to be fixed. cheers!
Cool, reopening so that I can change the status to FIXED then. :-)