GNOME Bugzilla – Bug 662672
wrong count of unread messages and text missing
Last modified: 2014-05-14 08:03:27 UTC
(Empathy 3.2.0.20111008) In the window title of a chat window I have "Contact Name (1 unread)" while I am actively discussing (it never disappear, until I close/reopen the chat window). The gnome-shell thingy with the count of unread messages is not present.
I can confirm that. Furthurmore, I'm not sure whether it can be considered as the same issue or not, but I regularly bump into a situation which gives me a negative counter for unread messages. And in that case, the bug reported above arises every time. I think this is caused by the gnome-shell integration. I can't reproduce the bug right now so I can't tell for sure, but I'd say it usually appears when there are several conversations involved.
*** Bug 711599 has been marked as a duplicate of this bug. ***
*** Bug 700631 has been marked as a duplicate of this bug. ***
Did anyone manage to find a way to reliably reproduce this?
This is happening every single time when i get a new message. Am using jabber. Am running kde - 4.12.1 empathy - 3.10.3 Archlinux Kernel: 3.12.9-1-ARCH I am able to reproduce it by following steps. 1. close all the empathy windows. 2. send some 2 messages. 3. This dosent open any chat windows. 4. Click the notification and click "response" 5. This opens the chat window and the first message will be missing. Here is the screenshot http://i.imgur.com/6Kl3GSn.jpg the first message "Hi Please let me know how to enter...." is missing.
(In reply to comment #5) > This is happening every single time when i get a new message. Am using jabber. I see exactly the same on Fedora 20 (empathy-3.10.3-1.fc20.x86_64). I am also on jabber and the first message of incoming notifications is missing in the chat window with "-1 unread messages".
Similar report on Ubuntu (empathy 3.8.6) https://bugs.launchpad.net/empathy/+bug/1261060 I'm able to reproduce it on a google (gtalk) account (configured through uoa) by doing: - open the empathy contact list - select the contact that is going to send you a message - clear the history - send the message - open it by clicking the buddy list entry -> the dialog which opens is missing the message and has an unread count of -1
I'm updating the version, to reflect the comments and updating title/importance. The issue is not only a wrong count, but the chat windows is missing received messages when that happens
After some digging in the source, I've found that this bug goes away when reverting cce06085 (the fix to bug #603980). I also can't reproduce bug #603980 anymore after reverting the fix. I don't feel confident enough in empathy's (and telepathy's) source to say this is the definite solution, though.
Ok, I think I've got a good understanding of what's going on now. It's a mix of 2 things: 1) For historical reasons (bug #603980) we delayed displaying received messages until we added backlog messages because we were only able to append messages in the chat window. But now the backlog messages are prepended so there is no reason to delay pending messages anymore. So indeed we can revert commit cce06085 and that fixes this bug as we would display pending message as soon as they arrives without waiting for the backlog. 2) The root cause is actually in got_filtered_messages_cb(). We start by fetching the first 5 messages of the backlog, and we call show_pending_messages() only if there are more than 5 messages in the backlog... WHY??? I think the show_pending_messages() call should not be inside that if(!tpl_log_walker_is_end (priv->log_walker)) block. So this bug only happens when receiving a message from someone with who you have 5 or less messages in the backlog.
Created attachment 274906 [details] [review] EmpathyChat: Fix pending messages not being displayed We don't have to wait for backlog to be inserted before adding pending messages anymore since backlog are prepended in the view.
Review of attachment 274906 [details] [review]: ++ thanks!
Thanks, pushed to master, 3.10 and 3.8. Distros should add that patch in their packaging IMO.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.