thats bad. marking as blocker

It seems this is an X issue. Can you run:

    GDK_SYNCHRONOUS=true gnome-shell --sync --replace

and get the real X error from stdout / stderr?

$ GDK_SYNCHRONOUS=true gnome-shell --sync --replace
      JS LOG: GNOME Shell started at Sat Feb 16 2013 11:22:31 GMT+0900 (KST)

(gnome-shell:17148): Clutter-WARNING **: ./clutter-actor.c:9704: Actor '<panelBox>[<StBoxLayout>:0x2ce8190]' tried to allocate a size of 1920.00 x -1.00
창 관리자 주의: Log level 8: atk_object_notify_state_change: assertion `ATK_IS_OBJECT (accessible)' failed
창 관리자 주의: Log level 8: atk_object_notify_state_change: assertion `ATK_IS_OBJECT (accessible)' failed

(gnome-shell:17148): Clutter-CRITICAL **: clutter_x11_get_stage_window: assertion `CLUTTER_IS_STAGE (stage)' failed
창 관리자 주의: Log level 6: The program 'gnome-shell' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 29672 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.)
추적/중단점 함정 (core dumped)

(In reply to comment #3)

Core was generated by `gnome-shell --sync --replace'.
Program terminated with signal 5, Trace/breakpoint trap.

+ Trace 231522

xorg-x11-server-1.13.99.902-1.20130215.fc19(1.14 rc2)
libX11-1.5.0-3.fc18.x86_64
clutter-1.13.4-4.fc19.x86_64

After downgrading to xorg-x11-server-1.13.2

Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal 5, Trace/breakpoint trap.

+ Trace 231523

I don't get a crash anymore, but I get a stuck osd situation, if I do the following:

1) Super-M
2) Super-Space

now the message tray and the osd are both visible, and the osd does not react to further Super-Space or Space key presses. I have to dismiss the message tray before I can get rid of the OSD.

Rui, can you have a look ?

The problem is that SwitcherPopup relies on being able to pushModal(), setting the stage input mode to FULLSCREEN, and then doing regular event processing on the actor it adds to uiGroup. But MessageTray uses GrabHelper which sets up a 'captured-event' handler on the stage and thus gets all events itself.

The only way I can see to make this work is having a global GrabHelper instance and port every use of pushModal() to use that instance instead. It goes without saying that I don't feel comfortable doing that at this point in the release cycle.

I think that for 3.8 we should just prevent the switcher from working in the message tray which is far from ideal, I admit, since we still have the chat bubbles in there...

Created attachment 237983 [details] [review]
status/keyboard: Don't allow the switcher in the message tray

SwitcherPopup relies on being able to pushModal(), setting the stage
input mode to FULLSCREEN, and then doing regular event processing on
the actor it adds to uiGroup. But MessageTray uses GrabHelper which
sets up a 'captured-event' handler on the stage and thus gets all
events itself.

This, of course, breaks the switcher if it's brought up in the message
tray so, for now, we'll just prevent it from being used there.

Review of attachment 237983 [details] [review]:

Looks good.

Attachment 237983 [details] pushed as e5ca53e - status/keyboard: Don't allow the switcher in the message tray