Comment 6 for bug 905417

Ah fun, based on some reading of the code I did it looks like this is a race condition where a window is destroyed, and then we make a bamf call on it, and during the time when we go to make that bamf call to fake re-minimize the window (required), "Closed" has already been emitted but we haven't yet gotten around to processing it, so the client side BamfView * points to an object which has already been destroyed bamfdaemon side, so bamfdaemon just doesn't return because the view doesn't exist.

Fun.

I see three solutions to this problem:

1) Hack around it and don't allow windowNotify to be called for destroyed windows in unity, that solution isn't perfect since another plugin could easily trigger the same effect if unity doesn't disable its windowNotify handler in time, and we may need to use the windowNotify handler in the destructor for other reasons..
2) Make libbamf use dbus_g_proxy_call_timeout to handle the situation where the server never replies
3) Make the server reply with an error if some client tried to make a proxy call with a proxy client that doesn't exist server-side because it was destroyed.

Out of all the three, solution 3 is the least hacky but might take some co-ordination in the SRU to get right. Solution 1 is doable, but I wouldn't recommend it for unity trunk.