GNOME Bugzilla – Bug 145131
No titlebar on windows without WM_NORMAL_HINTS (random)
Last modified: 2005-02-05 03:04:43 UTC
Description of Problem: When multiple windows are created, wm sometimes forgets to decorate some of the created windows window with a caption. The window otherwise does fine, and can be dragged with alt+left click. Steps to reproduce the problem: Version: metacity 2.8.1-3 (Debian Sarge) ========================================= == captionbug.c begin #include <X11/Xlib.h> #include <stdio.h> // gcc captionbug.c -lX11 -L/usr/X11R6/lib main(){ int i; XEvent ev; Display *dpy= XOpenDisplay(0); int screen=XDefaultScreen(dpy); for (i=0; i<5; ++i){ Window wnd=XCreateSimpleWindow( dpy, DefaultRootWindow(dpy), 0, 0, 320, 240, 0, BlackPixel(dpy, screen), WhitePixel(dpy, screen)); XSelectInput( dpy, wnd, StructureNotifyMask | KeyPressMask | ExposureMask | ButtonPressMask); XMapWindow(dpy, wnd); } while (1){ XNextEvent(dpy, &ev); } } == captionbug.c end ========================================= Actual Results: There is no regular pattern, sometimes all captions are there, sometimes 2-3 captions miss. Expected Results: I would expect all captions to be there. How often does this happen? The problem always showed at least after 5 invocations of the test program. Additional Information: The program does fine on metacity 2.4.55 (Suse9).
I forgot to metion that both testing machines have dual CPUs...
Sorry for the slow response, but thanks for the awesome test case. Maybe now we can track down the bug reports we've gotten about undecorated windows appearing. I can confirm this--with the given program, I occasionally get one of the windows to be undecorated...
Besides with my application, the same problem arises when starting OpenOffice and acroread. Other programs always have the caption in place. Besides at debian sarge (2xXeon), the problem also arises at MacOS X (2xPowerPC), but never at Suse 9.0 (2xOpteron).
Bug 133584 is probably a duplicate. So it appears we have duplicates with links2/glinks (from bug 138661 which is a dupe of 133584) and acroread as well. I only had a few minutes to look at this, but running metacity under valgrind appears to give some uninitialized variable warnings when this test program is run. Hopefully I can track those down and one of those turns out to be the problem...
*** Bug 133584 has been marked as a duplicate of this bug. ***
*** Bug 166205 has been marked as a duplicate of this bug. ***
Owen pointed out that this is related to WM_NORMAL_HINTS. He also provides another testcase we can use. Although I have no clue whether I'll be able to solve this by 2.10, I'm going to throw it on that milestone anyway.
Created attachment 36952 [details] Portion of the valgrind log relevant to the window appearing from Owen's testcase
Created attachment 36955 [details] [review] Initialize window->border_only So, I believe this could have happened with just about any window, because we only ever set window->border_only in recalc_window_features(). Since it's an uninitialized variable thing, it probably just depended on what was in the heap/stack so we were just lucky that they test cases seem to be likely to set memory up just right. It also explains why, in one of the bug reports, the user says they were able to get the border back by interacting with the window. (I just tried it out, and yes, maximizing windows like these without a border via keybindings will return the border)
Created attachment 36959 [details] [review] Alternate way to initialize window->border_only Oops, spoke too soon. :-} window->border_only would be initialized for all windows except those that didn't set MWM hints--I missed the recalc_window_features() call at the end of update_mwm_hints(). So, this patch just makes sure that recalc_window_features() is called before any exit from update_mwm_hints(), which I think is a cleaner fix.
Comment on attachment 36959 [details] [review] Alternate way to initialize window->border_only Thanks, good catch. This one may be worth putting in 2.8 also?
Committed to HEAD and gnome-2-8. 2005-02-04 Elijah Newren <newren@gmail.com> Make sure window->border_only is initialized so we don't get random windows without decorations. Thanks to Sinisa Segvic and Owen Taylor for providing test cases. Fixes #145131. * src/window.c: (update_mwm_hints): Be sure to call recalc_window_features even if no MWM hints are set