Very short-lived windows cause stuck "dead window" #340

Closed
TJC opened this Issue Feb 17, 2012 · 63 comments

Comments

Projects
None yet

TJC commented Feb 17, 2012

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 commented Feb 17, 2012

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

TJC commented Feb 17, 2012

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

Owner

clefebvre commented Feb 17, 2012

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.

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...

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()

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 commented Mar 27, 2012

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.

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 commented Mar 27, 2012

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!

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...

Member

AlbertJP commented Mar 30, 2012

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

Contributor

scotte commented Apr 13, 2012

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 commented Apr 20, 2012

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 commented Apr 20, 2012

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".

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.

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

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

TJC commented May 31, 2012

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

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

Contributor

ebbes commented Jun 11, 2012

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.

Member

AlbertJP commented Jun 11, 2012

@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.

Contributor

ebbes commented Jun 11, 2012

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

Contributor

ebbes commented Jun 11, 2012

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.

Owner

clefebvre commented Jun 12, 2012

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

Contributor

ebbes commented Jun 12, 2012

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.

Contributor

ebbes commented Jun 12, 2012

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

Member

AlbertJP commented Jun 12, 2012

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

Contributor

ebbes commented Jun 12, 2012

Well, according to #340 (comment) the bug seems to only occur on attached dialogs, not on other types of windows, so I only fixed that...

Contributor

ebbes commented Jun 12, 2012

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()
Owner

clefebvre commented Jun 13, 2012

Cool ebbes, send us a pull request.

Member

AlbertJP commented Jun 13, 2012

@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.

Contributor

ebbes commented Jun 13, 2012

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.

@ebbes ebbes added a commit to ebbes/Cinnamon that referenced this issue Jun 13, 2012

@ebbes ebbes Much simpler fix for Issue #340 a945375
Owner

clefebvre commented Jun 13, 2012

Fixed by b28d902

clefebvre closed this Jun 13, 2012

tap3ah commented Jul 4, 2012

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.

Member

AlbertJP commented Jul 4, 2012

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

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.

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 commented Aug 27, 2012

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

Contributor

dalcde commented Aug 27, 2012

Not reproduced for me

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

Contributor

dalcde commented Aug 27, 2012

I disabled desktop effects. That's why

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.

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!

Member

glebihan commented Dec 16, 2012

@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 commented Jan 26, 2013

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

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

cheers,
rsgirao

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

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

Owner

clefebvre commented May 23, 2013

Reopening.

clefebvre reopened this May 23, 2013

Member

AlbertJP commented May 23, 2013

@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 commented Jun 12, 2013

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.

fcole90 commented Jun 12, 2013

Anytime it happens to me I just ALT + T and then r to reboot cinnamon. It
works and I can continue to work without closing everithing =)

2013/6/12 renfeng notifications@github.com

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.


Reply to this email directly or view it on GitHubhttps://github.com/linuxmint/Cinnamon/issues/340#issuecomment-19315899
.

Cordiali saluti,
Fabio Colella

populov commented Oct 8, 2013

Could you assign higher priority to this bug, please? I like Cinnamon, but this bug makes almost impossible to work with IntelliJ IDEA normal way, because there are lots of short-living popups (intellisence hints and prompts) and they leave very many phantom windows.

Restarting Cinnamon every several minutes is not a nice workaround.

As a workaround now I use either Unity or Cinnamon with software rendering mode.
In software rendering mode bug doesn't appear.

Sometime it appears in some other apps except IntelliJ, but much more rare.

@populov , a bit above in the thread, and pointing to another issue, there is a workaround that works fairly well.

Just change your window effects to "scale" instead of "fade" and you won't have the issue anymore.

@areynaldos This does help some, but the error still pops up (doh) regularly.

populov commented Oct 10, 2013

@areynaldos your advice seems to work for popups inside IntelliJ / AndroidStudio, but now when I close or restart IDE (I often do it, switching between projetcs), I get this: https://www.dropbox.com/s/5foblt6uslogn9w/Cinnamon-bug.png
An ugly grey box on top of all windows, that doesn't disappear until Cinnamon restart.

I also tried the advice from @areynaldos, but this didn't work for me -- I'm using Krusader and when copying files or deleting files and quickly hitting enter to the dialog that appears, I get several dead dialogs.

ALT-F2 then "cinnamon --replace" will get rid of them as mentioned earlier.

Setting the close window effect to NONE solves the problem for me but -- I liked the fade effect. :-)

It seems to be fixed with Cinnamon 2.0.

Contributor

Rodsevich commented Oct 23, 2013

@populov on issue #1316 there's a pull request that solved the problem for me.
Would u mean trying to add that simple line that's added in the commit and give me feedback if the problem is solved for u too, please?

populov commented Oct 23, 2013

@Rodsevich I've applied patch, but I cant tell for sure, because it seems to be really fixed in 2.0

Contributor

Rodsevich commented Oct 23, 2013

@populov I had the problem while using Cinnamon 2.0.3, downloaded and installed directly from Github a very few days earlier (just with the only intention of getting rid of that problem)

@DorianScholz: Solved by changing the closing window time to 30 microseconds.

p91paul commented Dec 26, 2013

The issue is reproducible on cinnamon 2.0.14 on Arch Linux, using animation Scale - easeOutCirc - 250 ms on window close.
It can however be solved adding the 3-line patch from @ebbes (#340 (comment))

mtwebster closed this Aug 19, 2014

p91paul commented Aug 26, 2014

I can still reproduce the issue. Setting closing window time to 30 milliseconds is not a fix, since defeats the purpose of having an animation (you can't see the effect, it's too fast, and is the same as having no animation).
Is the patch from @ebbes included in a not-yet released version, enhce the bug is closed? otherwise please either include it or reopen this bug report. I see it in cinnamon 2.2.16.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment