ugh. ugly

Turns out that this happens in gnome-shell 3.8 too, if you force GTK to use proper client side decorations (ie patch gdk_window_supports_csd() to return true).

So it might be a gtk+ bug after all.

Just to blur the line, this does not happen in gnome-shell if you force attached-modal-dialogs to false, but it happens also if you patch gnome-shell to remove window dimming or map effects.

Switching to mutter, this never happens, with or without attached modal dialogs.

Similar behavior wrt mutter vs gnome-shell can also be observed in a control-center bug related to modal dialogs, where the dialog works correctly but the parent is frozen when the dialog is destroyed. This one is easily observed with the locations dialog from the search panel.

Created attachment 255446 [details] [review]
welp

this fixes it. don't ask me why or how. i've spent a lot of time investigating
and i have no idea why this would make any difference.

in order to "fix it", all three of these need to be run:

      priv->size_changed = TRUE;
      meta_window_actor_queue_create_pixmap (self);
      meta_window_actor_update_shape (self);

but we call sync_actor_geometry (); after all effects end and when we unthaw,
so i'm not sure why this isn't working.

i also have no idea why it fails in gnome-shell and not the default plugin.

*** Bug 708535 has been marked as a duplicate of this bug. ***

Review of attachment 255446 [details] [review]:

Well that looks like a effect is still in progress (windowManager.js) causing is_frozen to return TRUE and this sync_geometry is a nop.
The default plugin apperently either has no effect or finishes the effect faster (if it is a timing issue).

(In reply to comment #3)
> Just to blur the line, this does not happen in gnome-shell if you force
> attached-modal-dialogs to false, but it happens also if you patch gnome-shell
> to remove window dimming or map effects.

The map effect isn't a "freeze_thaw effect" so it is unlikely to be related. Was the window maximized?

Created attachment 255557 [details] [review]
untested hack

---

Does this work?
I cannot reproduce this bug here because every app that I tried to build and or run (gnome-clocks, gnome-music, gnome-contacts, gnome-wether, ...) either fails
to build or fails to start (and I don't really have time to rebuild "the world" right now to fix it).

What this hack does is to make sure that we remove all effects when kill-window-effects is emitted (which in theory shouldn't be needed) because we do that once the effect is done but well ... (I don't even know whether non maximized windows are affected or not).

(In reply to comment #8)
> Does this work?

No, and ...


> (I don't even know whether non maximized windows are affected or not).

... I can reproduce the issue with non-maximized gnome-contacts (more precisely: with a window that is not nor has been maximized)

Review of attachment 255557 [details] [review]:

Does not work.

(In reply to comment #9)
> (In reply to comment #8)
> > Does this work?
> 
> No, and ...
> 
> 
> > (I don't even know whether non maximized windows are affected or not).
> 
> ... I can reproduce the issue with non-maximized gnome-contacts (more
> precisely: with a window that is not nor has been maximized)

OK that does not make much sense ... can you try setting a breakpoint in meta_window_actor_freeze and see who / what (i.e get a backtrace) freezes the window?

(In reply to comment #6)
> Review of attachment 255446 [details] [review]:
> 
> Well that looks like a effect is still in progress (windowManager.js) causing
> is_frozen to return TRUE and this sync_geometry is a nop.
> The default plugin apperently either has no effect or finishes the effect
> faster (if it is a timing issue).

Sure, but sync_actor_geometry is called in both after_effects and in thaw:

https://git.gnome.org/browse/mutter/tree/src/compositor/meta-window-actor.c#n1202
https://git.gnome.org/browse/mutter/tree/src/compositor/meta-window-actor.c#n1012

(In reply to comment #12)
> (In reply to comment #6)
> > Review of attachment 255446 [details] [review] [details]:
> > 
> > Well that looks like a effect is still in progress (windowManager.js) causing
> > is_frozen to return TRUE and this sync_geometry is a nop.
> > The default plugin apperently either has no effect or finishes the effect
> > faster (if it is a timing issue).
> 
> Sure, but sync_actor_geometry is called in both after_effects and in thaw:

Yeah I know and given that is_frozen should be always FALSE in thaw it is probably after_effects.

Anyway we need to find out why the window is frozen and which effect is causing it. Giovanni said it is not the map effect and the map effect should not be freezing a window so no idea what is going on here ...

it's worse than that, last I tried debugging the freeze handling was correct and there was no effect running when it wasn't supposed to (so we would flush damage and update the texture correctly), but nothing was changing on screen

(In reply to comment #14)
> it's worse than that, last I tried debugging the freeze handling was correct
> and there was no effect running when it wasn't supposed to (so we would flush
> damage and update the texture correctly), but nothing was changing on screen

Jasper found out that it has nothing to do with effects but with the wm sync freeze handling. (disabling wm sync fixed it)

*** Bug 708702 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> (In reply to comment #14)
> > it's worse than that, last I tried debugging the freeze handling was correct
> > and there was no effect running when it wasn't supposed to (so we would flush
> > damage and update the texture correctly), but nothing was changing on screen
> 
> Jasper found out that it has nothing to do with effects but with the wm sync
> freeze handling. (disabling wm sync fixed it)

Not all of wm sync, but one specific bit:
if you patch away the is_frozen() check in meta_window_actor_sync_actor_geometry() everything works.

It also seems to be a timing issue, because if I break in gdb on the conditions that would make sync_actor_geometry() exit early, it then works fine, but blocks again as soon as I disable the breakpoint.

(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > it's worse than that, last I tried debugging the freeze handling was correct
> > > and there was no effect running when it wasn't supposed to (so we would flush
> > > damage and update the texture correctly), but nothing was changing on screen
> > 
> > Jasper found out that it has nothing to do with effects but with the wm sync
> > freeze handling. (disabling wm sync fixed it)
> 
> Not all of wm sync, but one specific bit:
> if you patch away the is_frozen() check in
> meta_window_actor_sync_actor_geometry() everything works.

Yeah the point was that it is not the freeze triggered by the effects but the wm sync one.

(In reply to comment #17)
> (In reply to comment #15)
> > (In reply to comment #14)
> It also seems to be a timing issue, because if I break in gdb on the conditions
> that would make sync_actor_geometry() exit early, it then works fine, but
> blocks again as soon as I disable the breakpoint.

Ok, this is definitely a timing issue, because a usleep(17000) (one frame) in that point makes the freeze a lot hard to achieve, and a usleep(34000) (two frames) removes it completely.

Obviously, dropping frames is not a solution, but we need to understand why it would make a difference.

Created attachment 255665 [details] [review]
MetaWindowActor: don't ignore window size changes when frozen

If we don't notice that the window size changes by queuing a new
pixmap from the server, we will keep drawing with the old pixmap
after unfreezing, and never see any application update.

*** Bug 708893 has been marked as a duplicate of this bug. ***