Stuck notifications (unable to clear them)

[Petr Jendrejovský]

There is no way how to clear all notifications for incoming messages at once. I have to click every single notification for every message received. This also means that every message (even from single contact) creates item in message notifications menu. "Clear" menu item is not working.

I am using Ubuntu 13.04 with package pidgin-libnotify 0.14-9ubuntu1.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[dimovnike (dimovnike)]

also a lot of repetitions are there, the same contact may appear many times.

[Jason Conti (jconti)]

There is an attempt in pidgin-libnotify to generate unique strings for each buddy, where each string is the id of a menu item in the Messaging Menu. If you are getting repeat entries, then for some reason it is generating two different strings for the same buddy.

If someone experiencing this bug could run: pidgin -d; when starting pidgin, and try to reproduce the bug. I'd be most interested in the results with lines like:

SOURCE activated '%s'

where %s is the buddy id. These would occur after clicking the menu item in the Messaging Menu for the buddy. It would be interesting to see how these differ for two different menu items for the same buddy.

Ideally I'd just like to see the entire log, but since that could reveal buddy ids, I'd be fine with someone going through and adding a comment with several examples of how the same buddy has two different ids (with names changed to protect the innocent).

Is this happening with Chat conversations or IM conversations (or both) ?

[Petr Jendrejovský (petr-jendrejovsky)]

Here are the lines you needed:

(22:24:03) pidgin-libnotify: SOURCE activated 'im:prpl-jabber:userone.recipient%40gmail.com%2Fdevoid:usertwo.sender%40gmail.com%2Fgemini2CEF0B0A'
(22:24:07) pidgin-libnotify: SOURCE activated 'im:prpl-jabber:userone.recipient%40gmail.com%2Fdevoid:usertwo.sender%40gmail.com%2FgeminiE558A939'

Here is the command used by monitoring to send the message:

MESSAGE="test"
SUBJECT="test"
echo "$MESSAGE" | sendxmpp -t -o gmail.com --message-type chat -r gemini -u $USER -p $PASSWORD -j $SERVER $RCPT -s "$SUBJECT"

(sendxmpp version 1.22)

Problem doesn't depends on "--message-type". Few minutes ago I tried to use GMail UI to send message. I saw only one notification. I also tried to use "common" jabber account (on njs.netlab.cz) and there was also only one notification.

This means problem in my case occurs only when using sendxmpp + gtalk.

[Jason Conti (jconti)]

Thanks for the information, the random characters at the end of the buddy name seem to be what's hurting us here. It seems that sender may contain too much information, looks like where the message originated from. Originally it was using purple_buddy_get_name() instead of sender, but for all the protocols I tested, these were the same, so went with sender instead.

Attaching a debdiff with the minor change of using purple_buddy_get_name() if possible, and if not falling back to sender. But since I can't reproduce this easily, I don't know whether this will fix your issue or not (it works equivalently on the protocols I'm using). For ease of testing, I pushed the change to ppa:jconti/gnome3 , it should build in a few hours. You don't necessarily have to add the ppa to test it, just downloading the deb and installing will work (or rebuild with the attached debdiff if you prefer).

If it doesn't fix the issue, I would be interested in seeing what the new buddy ids look like.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "pidgin-libnotify_use-buddy-name.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Petr Jendrejovský (petr-jendrejovsky)]

Great, I've installed deb file and it seems (partially) OK - now I can see only one item for each conversation. It was a real pain for me :).

But there are four problems now:

1) Only notifications for the second message from the same contact are displayed incl. notification bubble (I have to look at the workspace with Pidgin to see that someone new sent me a message). This is related to problem #2.

2) Envelope in Unity never turns blue. No matter how many new messages I've received, it's still black. But when I click it, I can see list of new conversations (conversations with unread messages).

3) In menu there is a "Clear" item, but now it's permanently "inactive" (grey).

4) When I enter the conversation menu item in Unity is still active (until I click on it).

This behavior is the same for all accounts/protocols I'm using (GTalk and XMPP). I'm not sure which of these problems were caused by this fix, because previously this notifications menu was so long I can scroll in it - every message from monitoring created new item.

P.S. Buddy IDs looks like this now:
(07:54:50) pidgin-libnotify: SOURCE activated 'im:prpl-jabber:userone.recipient%40gmail.com%2Fdevoid:usertwo.sender%40gmail.com'

[Sebastien Bacher (seb128)]

@Jason: thanks for your work

I can confirm that the first message received doesn't trigger a notification, that was happening before that update though. Testing the patch the envelop still turns blue as it should, I was not able to confirm the bug so I can't really confirm the fix but at least it seems to have no regression compared to the archive version...

Jason, do you want to have a look at addressing some of the issues from the previous comment before having it uploaded?

[Jason Conti (jconti)]

Thanks for testing. That buddy id was exactly what I was hoping to see, so at least that part seems to be fixed.

Problem 1, as Sebastien mentioned, was unfortunately always there. I'm not sure how to fix it. On my system at least, sometimes I will get the first notification, sometimes not. I think it could be related to the sign-on flood control code.

Problems 3 and 4 are actually by design. I think the Clear button's name is a bit misleading. It doesn't actually remove any of the menu items. It only clears the attention (the envelope changing color). Several separate menu items could all have attention set, and you would need to clear them all separately, so the button is just there to make it easy to remove them all at once. A menu item only disappears when you click on it, or when you close the conversation that is associated with it.

Problem 2 is interesting. For IM messages, the unseen-count of a conversation is used to determine if attention should be set. There could be two reasons why this isn't working. It could be that pidgin thinks you have the conversation focused for some reason. You said that you had it open on a separate workspace, so maybe it can't tell the difference. You could test this by minimizing the conversation and then sending the messages.

The other option is that for some reason purple_conversation_get_name() is not matching purple_buddy_get_name(). You said that it was working before, so that would point to purple_conversation_get_name() being the same as sender (so the buddy name with all the random bits at the end). If this is the case (we'd need to add some debugging messages to test), that would point to a bug in pidgin for that protocol, since the API reference says it returns "The conversation's name. If the conversation is an IM with a PurpleBuddy, then it's the name of the PurpleBuddy."

Actually looking at the jabber protocol code, in message.c they use purple_conversation_set_name() and describe it as:

* We received a message from a specific resource, so
* we probably want a reply to go to this specific
* resource (i.e. bind/lock the conversation to this
* resource).
*
* This works because purple_conv_im_send gets the name
* from purple_conversation_get_name()

So it seems it might be a quirk of the jabber code. Unless I could somehow get a buddy back out of a conversation, then I'm not sure how to fix this.

Sebastien, it's hard to say. It's probably better that the envelope doesn't change color when it should, versus flooding the Messaging Menu with duplicate entries. I'm not sure how fixable this is without adding some custom parsing for conversations with the jabber protocol.

[Jason Conti (jconti)]

Though now I'm concerned that the patch will break jabber users where it previously worked because they didn't have random strings at the end, but still don't have purple_buddy_get_name() matching purple_conversation_get_name()...

[Jason Conti (jconti)]

After a few minutes thought, I realized if purple_conversation_get_name() == sender, and I can get the buddy with account and sender, then I should be able to do the same with the conversation name. So I have pushed a new test package to ppa:jconti/gnome3. Please test it out and let me know if it fixes problem 2. Thanks!

[Petr Jendrejovský (petr-jendrejovsky)]

As far as I can say after short testing - when I receive more than 1 message from any contact, all notifications are working now (for all contacts). Except notification bubble for new conversations (but envelope turns blue so I know I have a new message). Problem #2 is solved for me, thank you!

[Jason Conti (jconti)]

Thanks again for testing.

In my haste, I forgot to update the other location where purple_conversation_get_name() was used, when deleting the conversation. I pushed one last change out to ppa:jconti/gnome3, if you wouldn't mind checking that closing a conversation window removes the associated menu item in the Messaging Menu that would be great (may also want to check first that it is broken with the current version).

[Petr Jendrejovský (petr-jendrejovsky)]

Yes, you are right - it was broken in ppa2 version. But now it works - when I close conversation (even when there are unread messages), item from menu is removed. And when envelope is blue because of unread conversation I'm closing, it turns black as it should.

[Sebastien Bacher (seb128)]

That version seems to work fine, I'm sponsoring it to saucy

[Launchpad Janitor (janitor)]

This bug was fixed in the package pidgin-libnotify - 0.14-9ubuntu2

---------------
pidgin-libnotify (0.14-9ubuntu2) saucy; urgency=low

  * debian/patches/messaging_menu.patch:
    - Use purple_buddy_get_name() instead of sender in unique id if possible
    (LP: #1175537)
    - Associate a buddy name with a conversation if possible, otherwise fall
    back to the name of the conversation.
 -- Jason Conti <email address hidden> Mon, 20 May 2013 18:20:04 -0400

[Benjamin Xiao (ben-r-xiao)]

I still get this issue with pidgin-libnotify 0.14-9ubuntu2~raring~ppa3 from ppa:jconti/gnome3

When I click on the chat window upon receiving a message, the blue mail indicator does go away, but the list of names is still there. The "Clear" menu item is also grayed out.

I am using a Jabber account with pidgin.