GNOME Bugzilla – Bug 334899
Minimize, right-click, "close" - does NOT raise gedit and show dialog
Last modified: 2006-04-17 04:04:41 UTC
Please describe the problem: A computer-illiterate friend of mine tried working with gnome, and his way of closing programs is right-clicking on the taskbar-entry and choose "close". When an app is minimized, this doesn't work, because the close-dialog is hidden. Steps to reproduce: 1. Open gedit, do a modification so closing will need confirmation. 2. Minimize gedit/show desktop. 3. right-click gedit panel-entry, click "close" Actual results: Nothing seems to happen. A close confirmation dialog is opened but hidden. Expected results: Raise gedit and show confirmation dialog. Does this happen every time? Yes, reproducable, always. Other information: Also a problem for GIMP, firefox, possible lots more. Abiword has got this right.
By the way: This problem wasn't present in gedit 2.12, I believe. See also my previous reports in Ubuntu, which aren't fixed yet: https://launchpad.net/distros/ubuntu/+source/gimp/+bug/4407 https://launchpad.net/distros/ubuntu/+source/metacity/+bug/4406 Gnome programs with same problem are reported to be: gnome-terminal (multiple tabs) evolution (unsaved composed mail) gthumb (unsaved transformation) inkscape (unsaved changes) gvim (unsaved changes) eclipse (unsaved changes)
Created attachment 61532 [details] [review] Show window with confirmation dialog.
Hi. Thanks for the patch. Yes, we could definately apply this workaround. Note that gedit-session needs the same trick. However I think we should really file a bug against metacity, I think the window manager should take care of that.
I agree with you.
(cc'ing elijah) Elijah, what should we do with this bug? Can it be fixed in metacity or should we apply the workaround? Or maybe do both... [feel free to reassign the bug to metacity if it can be fixed there]
I'm pretty sure this is a metacity bug. Fixing this probably just means unminimizing the window and the windows it is transient for (which I think we have a function for) when we create a new window (set meta_window_new_with_attrs()). Might be a one-liner, so it's probably a good bug for someone trying to get involved with Gnome. More details on how this bug probably appeared, for the curious: We have a window_should_be_showing() function that exists to check all the special reasons we might normally not want to show a window (it's minimized, the workspace is in showing desktop mode, an ancestor is minimized and thus the transient should be too, the window is on a different workspace than the active one, and maybe another I'm forgetting). We had lots of bugs where we kept hardcoding window->minimized instead of using the more general window_should_be_showing(), tried to purge those a while ago, and didn't catch any side-effects. The behavior probably used to be that the transient was shown, but that the parent wasn't, so it seems like the bug used to be different but not bad enough for people to notice.
Oops, actually adding the gnome-love keyword this time. Again, I think it's likely a small fix to meta_window_new_with_attrs to unminimize the window's parent(s).
Updating to the patch status to get it off the radar, as there's a simple fix that will work for all programs that can be applied to metacity.
I am not sure where in meta_window_new_with_attrs() this should go. It works at the very end, but it seems out of place there.
It probably makes most sense to put this next to where we show the window itself (or, well, put it in the queue for showing). I believe we also show transients of the new window if any exist at the same place, so adding code to show-ancestors-of-the-new-window would probably make sense there as well.
Created attachment 63649 [details] [review] Unminimize new windows to prevent an application appearing locked * window.c (meta_window_new_with_attrs): Unminimize new windows and transient parents to prevent confirmation windows from causing applications to appear locked when closed using the window list. Fixes #334899.
There was one small mistake in the patch: + unminimize_window_and_all_transient_parents(window); should have been + unminimize_window_and_all_transient_parents (window); (note the space between the function name and the opening parenthesis). But I just fixed that up when I committed it. Thanks!