GNOME Bugzilla – Bug 629557
Focusing on a new chat notification causes it to shrink and expand if additional messages are received.
Last modified: 2011-01-18 20:25:15 UTC
Due to recent changes: https://bugzilla.gnome.org/show_bug.cgi?id=617209 All new notifications start in summary mode. Unfortunately this conflicts slightly with telepathy in-notification chats. If a user receives a new chat notification and mouses over it the chat will expand. The user can then type. If the user receives additional messages while the chat is expanded the chat will reduce to summary mode and then re-expand rather than simply updating with the new message.
Created attachment 178193 [details] [review] Don't reset y position of expanded notifications when updating them This fixes the problem of chat notifications collapsing and then expanding again when receiving multiple messages in the expanded new notification.
Comment on attachment 178193 [details] [review] Don't reset y position of expanded notifications when updating them It seems to me that this patch shouldn't result in any behavior change. And the changes to the comments don't make it clear to me what it's supposed to be doing. What exactly is causing the chat to be reduced to summary mode now, and how does this patch prevent that?
The main change in the patch is that it does not tween y to 0 for expanded notifications that are getting updated, which resulted in the chat collapsing. The comments just explain everything that the code is doing.
but, as explained by the existing comments, the initial tween to 0 should have been irrelevant for expanded notifications, because the immediately following call to this._expandNotification() would overwrite it. So... what's going wrong?
So the uncertainty in timing and the delay in overwriting the tween was exactly what resulted in the notification collapsing sometime (i.e. the first tween that tweened y to 0 completing), and only then expanding. We should not be starting to tween y to 0 for expanded notifications.
*** Bug 639328 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > So the uncertainty in timing and the delay in overwriting the tween There's no uncertainty or delay; the tween does not actually start until you return to the main loop, and so if you overwrite a tween before returning to the main loop, then it's exactly the same as if you never started that tween to begin with.
Discussed on IRC that while in theory the second tween should be started synchronously before returning to the main loop, it doesn't appear to do so in testing, so the patch is ok because it only modifies a small piece of functionality, improves comments, and fixes the problem.