After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694057 - BadWindow X error closing telepathy chat
BadWindow X error closing telepathy chat
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: message-tray
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-02-18 00:44 UTC by Giovanni Campagna
Modified: 2013-02-18 17:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
StEntry: don't set the cursor on a NULL stage (872 bytes, patch)
2013-02-18 00:49 UTC, Giovanni Campagna
none Details | Review
StEntry: reset the cursor when unmapped (2.20 KB, patch)
2013-02-18 17:06 UTC, Giovanni Campagna
committed Details | Review

Description Giovanni Campagna 2013-02-18 00:44:48 UTC
Steps to reproduce:
- Go to the overview
- Open a telepathy chat in the summary area
- Hover/click the entry.
- Press Esc

Symptoms:
(gnome-shell-real:29620): Clutter-CRITICAL **: clutter_x11_get_stage_window: assertion `CLUTTER_IS_STAGE (stage)' failed
== Stack trace for context 0x1a5ca30 ==

Avviso del window manager: Log level 6: The program 'gnome-shell-real' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 11900 error_code 3 request_code 2 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Diagnosis:
The entry is removed without first seeing a leave event, since the mouse is not moved. When we next sync the pointer at the end of the modal grab, it gets the leave event it needs, but it is no longer parented to the stage, so it doesn't get a good X window.
Comment 1 Giovanni Campagna 2013-02-18 00:49:37 UTC
Created attachment 236514 [details] [review]
StEntry: don't set the cursor on a NULL stage

If we are unparented before we can reset the cursor, reset that of
the default stage.

This fixes the crash, but it's ugly, uses a deprecated function
and most of all doesn't reset the cursor correctly.
Comment 2 drago01 2013-02-18 15:35:50 UTC
Review of attachment 236514 [details] [review]:

Ugh ... how about net setting the cursor until we have a stage (parent) again?
Comment 3 Giovanni Campagna 2013-02-18 15:37:27 UTC
We may never have a stage again, for example if you never reopen the notification.
And then you're stuck with the I-beam cursor until you hover some other entry.
Comment 4 Emmanuele Bassi (:ebassi) 2013-02-18 16:38:55 UTC
if you use the default stage, you're just creating a new X11 window (and not mapping it).

using the default stage is most definitely wrong in any and all cases.
Comment 5 Giovanni Campagna 2013-02-18 17:06:51 UTC
Created attachment 236630 [details] [review]
StEntry: reset the cursor when unmapped

We cannot reset the cursor at the next leave event, as that might
happen on a NULL stage and cause a BadWindow error, so do it on
unmap (which is guaranteed to happen before the stage is cleared).

In the end I went with unmap rather than parent_set because it
handles also the case where the actor is hidden without unparenting
(not relevant to the shell now, but useful in general)
Comment 6 drago01 2013-02-18 17:08:27 UTC
Review of attachment 236630 [details] [review]:

OK.
Comment 7 Giovanni Campagna 2013-02-18 17:21:05 UTC
Attachment 236630 [details] pushed as 5e87fea - StEntry: reset the cursor when unmapped