1
0
Fork 0

frame: remove unnecessary server grab

meta_window_ensure_frame() creates its own grab and has a comment
claiming that it must be called under a grab too.

But the reasoning given in the comment does not seem relevant here.
We only frame non-override-redirect windows, so we are creating
the frame in response to MapRequest. There is no way that the child
could receive a MapNotify at this point, since that only happens
much later, once we go through the CALC_SHOWING queue and call
XMapWindow() from meta_window_show().

Remove the unnecessary grab.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
This commit is contained in:
Daniel Drake 2014-01-02 09:49:10 -06:00
parent 0e9491a415
commit fef32fb0d4

View file

@ -51,9 +51,6 @@ meta_window_ensure_frame (MetaWindow *window)
if (window->frame)
return;
/* See comment below for why this is required. */
meta_display_grab (window->display);
frame = g_new (MetaFrame, 1);
frame->window = window;
@ -117,14 +114,6 @@ meta_window_ensure_frame (MetaWindow *window)
meta_display_register_x_window (window->display, &frame->xwindow, window);
/* Reparent the client window; it may be destroyed,
* thus the error trap. We'll get a destroy notify later
* and free everything. Comment in FVWM source code says
* we need a server grab or the child can get its MapNotify
* before we've finished reparenting and getting the decoration
* window onscreen, so ensure_frame must be called with
* a grab.
*/
meta_error_trap_push (window->display);
if (window->mapped)
{
@ -166,8 +155,6 @@ meta_window_ensure_frame (MetaWindow *window)
/* Move keybindings to frame instead of window */
meta_window_grab_keys (window);
meta_display_ungrab (window->display);
}
void