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.
** Also affects: bamf
Importance: Undecided
Status: New
** Changed in: bamf
Assignee: (unassigned) => Jason Smith (jassmith)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/905417
Title:
Freeze when minimizing windows
To manage notifications about this bug go to:
https://bugs.launchpad.net/bamf/+bug/905417/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
