GNOME Bugzilla – Bug 593887
Wine windows behave strange in the overview
Last modified: 2010-10-25 14:56:52 UTC
Steps to reproduce: 1. Have two workspaces open in the overlay (let's call them A and B) 2. Start a Wine application (I noticed this using Spotify) and put it on workspace B. 3. Use overlay to switch from workspace B to workspace A. Notice that the Wine application window is visible on workspace B as it should be. 4. Open overlay again (from workspace A this time) and look at the miniature of workspace B. Expected result: Wine application window is visible and behaves as any other window. Actual result: Wine application window is not visible, but putting the cursor over where it should be activates the "hover" text displaying its name ("Spotify"). Clicking where the window should be when the hover text is active brings up the apllication just as it should. Seems like the window is not rendered, but the windowing system (not sure about terminology here) knows where it is and how big it should be. This is with gnome shell checked out from git. "jhbuild info" output below: Name: gobject-introspection Module Set: gnome-shell Type: autogen Install date: 2009-09-01 19:48:10 Git-Module: git://git.gnome.org/gobject-introspection Tree-ID: bd2e04700ac0fbee6bb82032b5bda6bb2177ec0b Required-by: gnome-shell, clutter, gir-repository, gjs Name: gnome-shell Module Set: gnome-shell Type: autogen Install date: 2009-09-01 19:49:06 Git-Module: git://git.gnome.org/gnome-shell Tree-ID: 687814b6c6bb8cef70e96520bbea004cb88b8c1f Requires: gobject-introspection, gir-repository, mutter, gjs, gconf Name: clutter Module Set: gnome-shell Type: autogen Install date: 2009-09-01 10:10:18 Git-Module: git://git.clutter-project.org/clutter Tree-ID: 2b5107acc076a5750858d9cd48cb30e67ce97cbb Requires: gobject-introspection Required-by: mutter Name: gir-repository Module Set: gnome-shell Type: autogen Install date: 2009-09-01 10:09:18 Git-Module: git://git.gnome.org/gir-repository Tree-ID: 87a7cc5886750a96ea5322371d8fc500644ab896 Requires: gobject-introspection Required-by: gnome-shell, mutter Before: gjs Name: gconf Module Set: gnome-shell Type: autogen Install date: 2009-09-01 10:10:41 Git-Module: git://git.gnome.org/gconf Tree-ID: 5b95ea4da75a141f5bae02774d516ee90ae24ded Required-by: gnome-shell, mutter Name: gjs Module Set: gnome-shell Type: autogen Install date: 2009-08-31 11:41:33 Git-Module: git://git.gnome.org/gjs Tree-ID: ae7349186cf52143367d304ea38323ac6bdf7e04 Requires: gobject-introspection Required-by: gnome-shell After: gir-repository Name: mutter Module Set: gnome-shell Type: autogen Install date: 2009-09-01 19:48:41 Git-Module: git://git.gnome.org/mutter Tree-ID: bd2e221da34f72dbcc6a1c0dc8fdae058ec93014 Requires: gir-repository, clutter, gconf Required-by: gnome-shell
I can confirm this. I get the error: fixme:ntdll:NtQueryInformationProcess (process=0xffffffff) Unimplemented information class: ProcessDebugFlags Over and over again in the terminal of gnome-shell using spotify. At the beginning of the application I also get: fixme:ntdll:NtQueryInformationProcess (process=0xffffffff) Unimplemented information class: ProcessDebugFlags over and over again. Not sure if this is related anyway but wanted to add them here.
The last one was wrong: I ment: fixme:xrender:X11DRV_AlphaBlend Ignoring SourceConstantAlpha 128 for AC_SRC_ALPHA
I can confirm this as well although I am using crossover office. In my specific case it happens with Microsoft Outlook which dissapears completely as I switch to other workspaces. To get the application back I have to either click on its tray icon and open outlook or launch the application again. I there is a need I can provide more detailed information provided someone can point to me more info on how to go about it ..
I confirm as well. Happens to me in TimeTo, running in Wine.
Created attachment 170433 [details] [review] Avoid confusion when _NET_WM_USER_TIME_WINDOW is in the window stack Wine sets _NET_WM_USER_TIME_WINDOW to point to an unmapped toplevel; this was causing much confusion because both the real window and the unmapped window were in the window stack and mapped back to the same MetaWindow. Debugged by Alban Browaeys
I confirm this new version of the patch also fixes the wine windows handling. Thanks again.
well though I found out when disabling log to file that: Log level 8: meta_display_register_x_window: assertion `g_hash_table_lookup (display->window_ids, xwindowp) == NULL' failed VERBOSE: mutter(meta_print_backtrace+0x1a) [0x4501ca] VERBOSE: /usr/local/lib/libglib-2.0.so.0(g_logv+0x1af) [0x7fc640f2e7ef] VERBOSE: /usr/local/lib/libglib-2.0.so.0(g_log+0x83) [0x7fc640f2ebf3] VERBOSE: mutter(meta_display_register_x_window+0x41) [0x433120] VERBOSE: mutter() [0x4527c5] VERBOSE: mutter() [0x4503af] VERBOSE: mutter(meta_window_load_initial_properties+0xcf) [0x452589] VERBOSE: mutter(meta_window_new_with_attrs+0x848) [0x45c2d2] VERBOSE: mutter(meta_screen_manage_all_windows+0x241) [0x4487c0] VERBOSE: mutter(meta_display_open+0x14ed) [0x437ed1] VERBOSE: mutter(main+0xad2) [0x441df2] VERBOSE: /lib/libc.so.6(__libc_start_main+0xfd) [0x7fc63f775c4d] VERBOSE: mutter() [0x422679] VERBOSE: Requesting 1 properties of 0x8600602 at once happens in reload_net_wm_user_time_window
(In reply to comment #7) > well though I found out when disabling log to file that: > Log level 8: meta_display_register_x_window: assertion `g_hash_table_lookup > (display->window_ids, xwindowp) == NULL' failed > VERBOSE: mutter(meta_print_backtrace+0x1a) [0x4501ca] > VERBOSE: /usr/local/lib/libglib-2.0.so.0(g_logv+0x1af) [0x7fc640f2e7ef] > VERBOSE: /usr/local/lib/libglib-2.0.so.0(g_log+0x83) [0x7fc640f2ebf3] > VERBOSE: mutter(meta_display_register_x_window+0x41) [0x433120] > VERBOSE: mutter() [0x4527c5] > VERBOSE: mutter() [0x4503af] > VERBOSE: mutter(meta_window_load_initial_properties+0xcf) [0x452589] > VERBOSE: mutter(meta_window_new_with_attrs+0x848) [0x45c2d2] > VERBOSE: mutter(meta_screen_manage_all_windows+0x241) [0x4487c0] > VERBOSE: mutter(meta_display_open+0x14ed) [0x437ed1] > VERBOSE: mutter(main+0xad2) [0x441df2] > VERBOSE: /lib/libc.so.6(__libc_start_main+0xfd) [0x7fc63f775c4d] > VERBOSE: mutter() [0x422679] > VERBOSE: Requesting 1 properties of 0x8600602 at once > > happens in reload_net_wm_user_time_window I can't see how this is related to my patch. Does it occur with metacity? Is there a deterministic way to trigger it? It sort of looks like two separate Wine windows might be sharing the _NET_WM_USER_TIME_WINDOW. Maybe you can check the Wine sources and see what they do with NET_WM_USER_TIME_WINDOW?
Ok I found out this was not an isuse with the patch . More a bug was hidding a second bug. The patch fixed the first one. The second one could be patched on the wine side : http://bugs.winehq.org/show_bug.cgi?id=23543 this second bug is gnome-shell bug report https://bugzilla.gnome.org/show_bug.cgi?id=625545 already attached to the wine bugzilla report http://bugs.winehq.org/show_bug.cgi?id=23543 where I posted my wine patch.
Attachment 170433 [details] pushed as ed9d7f1 - Avoid confusion when _NET_WM_USER_TIME_WINDOW is in the window stack
*** Bug 633009 has been marked as a duplicate of this bug. ***