False reports of "Window not responding" error

Confirmed with GNOME. It seems like GNOME's "Window Not Responding" detector is not the brightest thing alive. Basically, if the window isn't off the screen within a few seconds, GNOME will say that it's not responding.

The fix is probably complex at best though :-/

Thanks for your bug. I've no such issue on my i386 dapper, does anybody has an idea of what could trigger that behaviour for you?

Confirmed with KDE as well. It takes more than 1-2 seconds, but if I close a program with the X and some dialog pops up and for any reason I don't let the program close right away, that dialog comes up that the window is not responding.

Kubuntu AMD64 latest updates.

what version of Ubuntu do you use? Is that specific to gedit?

This should be filed as a separate bug, as KDE (KWin)'s inner workings are
different from GNOME's.

Recently I've been unable to reproduce these again, both on Dapper and
Breezy. I think it has to do with non-KDE, non-GNOME programs only (i.e.
Matlab still does this). I don't think there's much (if anything) we can do
about that.

On 3/16/06, Yuriy Kozlov <email address hidden> wrote:
>
> Public bug report changed:
> https://launchpad.net/malone/bugs/29584
>
> Comment:
> Confirmed with KDE as well. It takes more than 1-2 seconds, but if I
> close a program with the X and some dialog pops up and for any reason I
> don't let the program close right away, that dialog comes up that the
> window is not responding.
>
> Kubuntu AMD64 latest updates.
>

I've had the same problem on Dapper beta 2 amd64 with Firefox, OpenOffice, gedit, and The Gimp.

what do you do exactly to get those applications displaying that dialog?

In Firefox:
1. open a Firefox window
2. open a new tab (CTRL T)
3. try to close the window by hitting the "x" button up in the title bar
4. a dialog pops up with the text "You are about to close 2 open tabs. Are you sure you want to continue?"
5. wait 5 seconds (maybe a little more or less, I didn't measure it)
6. another dialog pops up that says the window is not responding, with options to cancel or force quit.

In OpenOffice.org or gedit:
1. open a new window
2. type some stuff
3. try to close the window by hitting the "x" button
4. get the "are you sure you want to quit" dialog
5. wait
6. get the "not responding" dialog

Similar for The Gimp.

The problem seems to have gone away after an apt-get update about an hour ago. I'll take a closer look tonight or tomorrow in the event that nobody can confirm that it's fixed.

My previous message should have said "upgrade" instead of "update". But you all knew what I meant, right?

Does anybody still have that issue?

Yes, I do. Here is how I can reproduce it:
Open a ssh connection.
Edit a file on the ssh connection with gedit
Press close.
Gnome will ask for the password to the ssh connection to edit the file.
Wait two seconds.
Metacity will then complain about the window not responding.

Latest dapper x86

I installed the release version this morning, and the bug is back.

I'm not sure what changed, as I was running an up-to-date dapper before the reinstall and it wasn't happening. Perhaps having also installed KDE and XFCE had something to do with it.

Bug is still present, tried in gedit and GIMP.

In pygtk at least, the problem seems to be due to a delete_event signal being captured and held onto whilst waiting for user input. I have a way round this for small apps, but it would be great to have it fixed at the source

on edgy gedit asks for the password on opening, closing the gedit window while the password dialog is opened leads a hang to the password dialog but no "Window not responding" message

I can confirm this. Thought it only happens in my amd64 box, but not with x86 box. Both are running Dapper with latest updates.

I have tryed debug this with older versions of metacity too, it seems to exist in version 2.10.3 of metacity too. I'm not even sure is this metacity problem(?)

Do all the people having that issue use and amd64 installation? I've commented upstream about that on http://bugzilla.gnome.org/show_bug.cgi?id=348305. That might be a GTK bug

Yes, what I have heard from people who have amd64 installation, it appears on them.

fixed upstream

That upload fixes the issue:

 metacity (1:2.16.2-0ubuntu1) edgy; urgency=low
 .
   * New upstream version:
     - partial audit to fix timestamp usage (partly fixes #355180)
     - remove compilation warnings
     - automatic detection of stable/unstable in configure script
     - make windows be stacked correctly before showing them (Ubuntu: #33879)
     - use guint32 for timestamps (Ubuntu: #29584)

opening a dapper task since the fix is easy enough and that would be nice to get a backport for dapper

Yes, I agree. It would be nice to see this fixed in Dapper.

Thank you for taking the time to report this bug and helping to make Ubuntu better. The version of Ubuntu you're reporting this issue on is in End of Life status, and newer versions have fixed this issue. You can learn more about this at https://wiki.ubuntu.com/Releases