Very short-lived windows cause stuck "dead window"

[TJC]

If a window is created and then destroyed very quickly, this often leaves behind a kind of "dead window" -- a bit of screen with an empty window that is in the foreground, but cannot be interacted with at all.

Examples of windows like this are dialogs that pop up to say "Saving, please wait" and the like, which automatically close once the file has saved.

I attach a Perl example that triggers the bug:

#!/usr/bin/env perl
use strict;
use warnings;
use Glib;
use Gtk2 '-init';

my $window = Gtk2::Window->new;
my $label = Gtk2::Label->new ('Hello World!');
$window->add ($label);
$window->show_all;
Glib::Timeout->add(100, sub { Gtk2->main_quit });
Gtk2->main;

[TJC]

See bug #309 for a probably-related similar issue.

[TJC]

PS. The above example requires you to have aptitude installed libgtk2-perl

[clefebvre]

Thanks, I'll mark the other bugs as duplicate of this one. The Perl script gives us a way to reproduce the problem easily and that's really handy!! Thanks.

[DorianScholz]

This happens to me a lot in firefox as I use the autoauth add-on which automatically fills in authentication dialogs and directly closes them again. To get rid of the empty dialog I have to restart firefox. Very annoying issue...

[DorianScholz]

As I could not reproduce the bug with the OPs code, I wrote another example that reproduces the bug on my system. The difference is that the main window stays open, only the popup dialog is closed by a timer. As soon as I close the main window, the dialog residues disappear as well.

The problem seems to completely disappear if I disable the desktop effects in the cinnamon settings.

With the effects on and set to 250ms I see different results, depending on the value of the close_delay variable: 0-60: no dialog at all 60-100: different amounts of the dialog frame remain visible without contents 100-300: the complete dialog frame remains visible with out contents 320+: the dialog is closed completely

So this bug seems to be related to the effect timings...

This example needs the package python-gobject to be installed.

#!/usr/bin/python
from gi.repository import Gtk
import glib

close_delay=150

class MessageDialogWindow(Gtk.Window):

    def __init__(self):
        super(MessageDialogWindow, self).__init__(title="MessageDialog Example")
        self.dialog = Gtk.MessageDialog(self, 0, Gtk.MessageType.INFO, Gtk.ButtonsType.OK, "This is an INFO MessageDialog")

    def show_dialog(self):
        self.dialog.run()
        self.dialog.destroy()

win = MessageDialogWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
glib.timeout_add(200, win.show_dialog)
glib.timeout_add(200 + close_delay, lambda: win.dialog.response(0))
Gtk.main()

[DorianScholz]

To familiarize myself with the Gjs javascript bindings I tried to reimplemented this script in JS. Even though I was not completely successful I learned something new about this bug on the way: This bug can only be seen for attached dialogs (the ones that stick to the title bar of a main window). This code produces a warning about the dialog being a top-level window and fails to run, unless you omit the "parent: win" part in the dialog constructor. But then the bug does not occur...

#!/usr/bin/gjs
const Gtk = imports.gi.Gtk;
const Mainloop = imports.mainloop;

let close_delay = 150;

Gtk.init(null, 0);

let win = new Gtk.Window({title : "MessageDialog Example"});
let dialog = new Gtk.MessageDialog({parent : win, type : Gtk.MessageType.INFO, buttons : Gtk.ButtonsType.OK, text : "This is an INFO MessageDialog"});
//          why does this not work? ^^^^^^^^^^^^^
win.connect("destroy", Gtk.main_quit);
win.show_all();

Mainloop.timeout_add(200, function () {dialog.run(); dialog.destroy()});
Mainloop.timeout_add(200 + close_delay, function(){dialog.response(0)});

Gtk.main();

[TJC]

Hi, If you're having trouble with my Perl code not producing the problem, please try tweaking the timeout value in the second-to-last line. Eg. Increase the 100 to 200.

Without having seen the Cinnamon code, it seems like the error occurs whenever a window closes while the open-animation is still running.

As a work-around, I can prevent the stuck windows from occuring by disabling the effect for "Mapping window" in the Cinnnamon Effects control panel.

[DorianScholz]

Hi TJC, I tried different timings in your example, but I could not reproduce the bug with your code. I think the difference is that your main window and the whole application are closed directly. When the main window to which the dead window belongs is closed, the dead window disappears as well (in my example as well as in i.e. firefox). This behavior might have changed when I upgraded from cinnamon 1.3 to 1.4. With 1.3 I think I had to restart cinnamon to get rid of the dead window, but I'm not completely sure. Which cinnamon version are you using? Have you tried your example (and mine) with cinnamon 1.4? Cheers, Dorian

[TJC]

I'm using the latest version of Cinnamon from the Ubuntu PPA -- which appears to be 1.2.0-2ubuntu1~oneiric

It looks to me like the person maintaining that PPA (merlwiz79) has stopped bothering? I'll see if I can find a more up to date one!

[allanfreitas]

hello, i was with that issue, but one day I have disabled cinnamon effects and no more troubles, i'm having this trouble with aptana studio...

[AlbertJP]

@TJC The merlwiz PPA is indeed no longer updated. This is the new one: https://launchpad.net/~gwendal-lebihan-dev/+archive/cinnamon-stable

[scotte]

As of Cinnamon 1.4 on LM12, this problem is still around.

One thing I have noticed is that while it happens frequently on one laptop (intel graphics using "intel" driver), it has never once occurred on my other laptop (nvidia graphics using "nvidia" driver). I suspect the video driver in use has something to do with the ability to easily reproduce this.

This is a super frustrating bug because the windows that are left over are always floating on top of everything else and cannot be closed.

[warkior]

Happening for me quite often in a variety of applications. Cinnamon 1.4 + LM 12 + nVidia. Most persistent in Eclipse. Same results as mentioned above... a modal window seems to be partially created but is left blank, and remains "stuck" on top regardless of workspace.

[warkior]

For the record, if you find this bug exceptionally annoying, it seems easy to "fix" by simply disabling desktop effects. Main Menu -> Preferences -> Cinnamon Settings -> Effects -> Uncheck "Enable Desktop Effects".

[Modulariti]

I also experience another issue. When opening Eclipse dialog window, it doesn't get focus immediately. I have to click it first. Not sure if this is problem with Cinnamon/Mint or Eclipse.

[Modulariti]

One thing to add, the above problem happens when a short live progress dialog preceeds the dialog.

[Pyrosopher]

Still an issue when using Inkscape. Shame to have to turn off the effects.

[TJC]

I had thought this was fixed, but then it happened to me again yesterday. Cinnamon Version: 1.4.0-UP3-0ubuntu1~precise1

[nikosdouvlis]

Same happens to me when using Eclipse. I really like the window effects and its a shame to disable them

[ebbes]

I experience this problem too, especially when debugging using MonoDevelop. Maybe an option in Cinnamon settings to disable attached modal dialogs would be cool for those experiencing this issue very often? Personally, I would more likely turn off attached dialogs than desktop effects. It would be easy to add to Cinnamon settings, but I don't know if it is missing for a special reason or simply because it was not yet added.

[AlbertJP]

@ebbes That dialogs are attached is mainly because the theme does not give window borders to them. The closing effect should be fixed here: right now it does not close the window, when the opening effect is not yet finished. That's why we have this bug. Of course cinnamon settings could be used to work around it if the option is added, but that's a hack and not a real fix.

[ebbes]

Yes, I'm aware of that. But I thought it could be cool until someone fixes the actual problem.

[ebbes]

Currently I am trying to fix this problem. Did some edits in /usr/share/cinnamon/js/ui/windowManager.js, seems to work. "Normal" modal dialogs work as before, short lived will show and fade out immediately without staying open. However, I will investigate and test it, if I think my fix is good enough, I will post it.

[clefebvre]

Thanks ebbes, let me know also if you've got an easy way to replicate the problem so we can test the fix easily.

[ebbes]

I reproduced the problem by running the python script published above. Another method could be building and debugging projects that immediately end using MonoDevelop, sometimes it will trigger a buggy modal dialog. Since the problem seems to be that windows cannot be closed until they are completely visible (i.e. animation is finished), I decided to check in the closing function whether opening animation is finished yet. If not, a variable is set indicating that closing is requested. When the opening animation finishes, it checks for this variable, if it is set, it calls the window closing function. Result is: If windows are opened and closed shortly after, they will have an opening animation and a closing animation; the user is still able to see that there was a dialog window that was closed immediately. See https://github.com/ebbes/Cinnamon/compare/patch-2 for my changes in windowManager.js.

[ebbes]

Some problems with last commit, reverted some other changes. https://github.com/ebbes/Cinnamon/compare/patch-3 is the correct one.

[AlbertJP]

I don't think it is right to fix this only for dialogs. The effect needs to be fixed for all types of windows.

[ebbes]

Well, according to https://github.com/linuxmint/Cinnamon/issues/340#issuecomment-4701008 the bug seems to only occur on attached dialogs, not on other types of windows, so I only fixed that...

[ebbes]

Modified DorianScholz's python script to create a short-lived window (non-modal), causes no problems, window appears and effect switches to fade out before fade in is finished.

#!/usr/bin/python
from gi.repository import Gtk
import glib

close_delay=150

class MessageDialogWindow(Gtk.Window):

    def __init__(self):
        super(MessageDialogWindow, self).__init__(title="MessageDialog Example")

    def show_dialog(self):
        self.dialog.run()
        self.dialog.destroy()

win = MessageDialogWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
glib.timeout_add(100, win.destroy)
Gtk.main()

[clefebvre]

Cool ebbes, send us a pull request.

[AlbertJP]

@clefebvre Are you sure that there is not another bug in the effects, that makes a difference between dialogs and normal windows where it shouldn't? It's surprising that windows don't have this bug when they aren't dialogs.

Maybe it's even a bug in Muffin.

[ebbes]

Well, I tried another approach, it is much simpler, only 3 lines and gets the job done...

    _destroyWindow : function(cinnamonwm, actor) {
        if (global.settings.get_boolean("desktop-effects")) {
            Tweener.removeTweens(actor);
        }
        [...]

I think this is even better as it uses far less code, stops the fade-in animation and switches to fade-out just as non-modal windows behave. Maybe calling Tweener.removeTweens(actor); right before Tweener.addTween for modal dialogs would be even better, it would not cause an unneccessary call for non-modal windows, although there is no visual difference.

[clefebvre]

Fixed by https://github.com/linuxmint/Cinnamon/commit/b28d90265e65e48a0168e33a550cc1b364bbcb40

[tap3ah]

For me, the issue seems to appear only if "Enable desktop effects on dialog boxes" is checked and "Closing windows" is on "Fade". If I change just one of those two, it works fine.

[AlbertJP]

@ tap3ah: This issue is closed. It is fixed in the latest Cinnamon git.

[wilecoyote2015]

I do still get dead non-dialog windows quite often in my build from the latest git. They are appearing randomly while using firefox when I click on links what makes a dead window pop up.

[wilecoyote2015]

On my system I can reproduce it in Nautilus. Create an empty document, rightclick it, Compress..., Create.

Because the compression is finished immediately the compressing window will turn into a dead frame.

[tap3ah]

I can confirm the bug is still here at version 1.5.2.

[dalcde]

Not reproduced for me

[wilecoyote2015]

I can also confirm that, as tap3ah mentioned, it does only occur when the closing windows effect set to fade (my setting: easeoutquad, 250ms

[dalcde]

I disabled desktop effects. That's why

[areynaldos]

I believe the issue hasn't been fixed. Ebbes fix works correctly. Clem added it, and then refactored, but I can only solve the problem with Ebbes original fix.

[tylerhuntjones]

Ok I have been experiencing this issue for well over a year now across three versions of Mint and a myriad of different applications. Although it doesn't bother me most of the time, every now and then I prevents me from completing an important action and I am forced to restart X or the system to clear it. (Actually, there is one on the other monitor as I type this: http://imgdump.me/eBzhom.png). I would gladly help dig around the system and attempt to offer my modest Linux skills to resolve this issue. I've waited a while to write this in the hopes that a solution or a good sugestion would be reported here. Nothing has worked so far. Anyway here is what I have noticed so far:

1) Short lived windows seem to be the most affected. But recently it has happened to 'Account Settings' in Thunderbird and other "longer lived" windows (Transmission, Arduino IDE). 2) It is very difficult to reproduce with the exception of some large java-based applications. (i.e. Eclipse, Netbeans, etc..). Even in the aforementioned programs and other application instances where this bug occurs it is hit or miss and almost random in how and when it occurs. 3) Keeping number 2 in mind, after a fresh reboot (not just a X restart) everything is fine for a couple hours of nominal usage then back to the usual. 4) Killing every process that has anything to do with the affected app (except for X) does not clear the window. So this would mean that Cinnamon isn't closing them properly after the application has quit. 5) In most cases (except for the screenshot above) the more RAM that cinnamon is using, the more likely the bug will occur. 6) Restarting X will clear the windows (obviously) 99% of the time. But every now and then, generally in Eclipse, numerous dead windows will appear and cause the system to lock up forcing a reboot.

That is my rant so far. I have recently started trying to collect as much info as I can about what went wrong and why but I'm not totally sure what I should be looking for. Tell me what logs I should collect or what info would be helpful and I will provide it. On average, during an 8hr day of system admining and multi-IDE programming, I will see 8-12 dead windows. Ignoring most of them for as long as I can it still cuts into my work time when I have to restart or reboot.

Thanks for all the suggestions so far, progress is progress even by process of elimination. Nothing will ever stop me from using Linux Mint and as a member of the open source community it is my duty to aid in fixing it. Let me know how I can help. Thanks!

[glebihan]

@inquirewue : for the record, you shouldn't need to reboot or even restart X to get rid of those windows : restarting cinnamon (via alt+f2 -> cinnamon --replace) should do it.

Apart from that, it's been a really long time since I last experienced this issues myself. I'll try a few of the cases you've mentioned there and see if I can get to reproduce it.

[rsgirao]

Works for me: open menu >preferences>cinnamom settings>effects;

Do not use "Fade" in the field "closing windows"

cheers, rsgirao

[bradtgmurray]

This still occurs for me even when I have all Effects disabled in the preferences.

[demonkoryu]

Just for the record, I'm having this problem only with IntelliJ IDEA. I've switched to Mate for the time being.

[clefebvre]

Reopening.

[AlbertJP]

@clefebvre We already have issue #1316 for this. For many people the problem is solved already, so this issue got closed - it remains for those who use the Fade instead of Scale effect, and that's discussed in #1316 and some other issues. (IIRC Fade became default in Mint 15?)

[renfeng]

I've seen such windows quit a lot when I was using eclipse. Sometimes, restart eclipse will clear it. Sometimes, I have to logout and login again to see it disappear.