Gaim 2.0.0beta6 - Jabber contact list one contact repeated

[cga]

Hi all =) i've searched for this bug but didn't find nothing.

On Gaim 2.0.0beta6 if you add a contact in jabber and modify it (like using an alias) it creates two different contacts even if it is the same. this also happens when you delete and re-send the auth for the contact. i've cheched with another jabber client (gajim) to see if i had only one contact as it should be, and on gajim is correct, one contact only.

thanks and keep up the good work for pidjin =)

[deryni]

What server is this on? Are you seeing new copies being added with the 2.0.0 (or later) release of pidgin? Can you show us the debug window output of your connecting to that account?

[cga]

Replying to deryni:

What server is this on? Are you seeing new copies being added with the 2.0.0 (or later) release of pidgin? Can you show us the debug window output of your connecting to that account?

the server is not the problem... as I wrote clearly the server is ok and has one contact only. I'm still using Gaim 2.0.0beta6 on Ubuntu 7.04 and i think i'll be fine with it until Gutsy Gibbon, so i can't tell about pidjin and >=2.0.0 ; debug an account???

[deryni]

Just because another client didn't show more than one copy doesn't mean the server isn't doing something 'odd'. Help->Debug Window then try to connect, then paste the xml, feel free to sanitize the buddy names if you want, but if you do you need to leave them unique (so each time you see buddy1 you make it foobar1, and buddy2 becomes foobar2, etc.).

[Dread Knight]

Same thing happened to me on Ubuntu 7.04 with pidgin 2.0.0 and 2.0.1.

After I've repeatedly deleted one of the clones things 'remained normal'.

[ryanb]

this is probably the same as http://developer.pidgin.im/ticket/1089 . you/we might want to close one of them as a dupe.

[seanegan]

duplicates: #1089 #2178

[seanegan]

Is this still happening?

[nclm]

As I said in #1089... yes

[nclm]

A adds B(using pidgin) to his list, B authorizes him. After that pidgin automatically adds contact A to B's list but doesn't send the authorization request (first bug) to A (needed that B can see A's status). Instead of that pidgin pops up the "Add Buddy" window on B's screen (2. bug), so he thinks he should now add A to his manually. After that B has to A entries in his list.

[phobie]

Replying to seanegan:

Is this still happening?

As you can see on #2178 this bug also applies to 2.1.1! I will test on 2.2.0 later...

[shreevatsa]

Still happening, has been happening for quite a while now. This is what I encounter (on Google Talk, at least):

• New friend adds me to his list.
• I get a request for authorisation.
• If I wait long enough before saying Yes or No (a minute should do it), the new contact gets created automatically, under the group "Buddies" (creating the group if it doesn't exist).
• Then when I finally say "Yes" putting him/her in another group, I have a duplicate.

(I don't know what happens when/if I say "No"... I've never denied anyone authorisation so far.)

[ArcFi]

I'm Pidgin 2.2.0 user and confirm the problem of duplicating XMPP-contacts. I've added some attachments as a proof.

I have an idea how to close this bug. Before adding new contact to certain account pidgin must check, if this contact has already been added to the account and restrict adding if it has.

Best wishes ;)

[deryni]

Unfortunately that is not really a valid way to handle this because having a buddy in more than one group is a perfectly valid thing to do for an XMPP account. Can you get and post the Debug Window output of this happening from start to finish?

[ArcFi]

Pidgig 2.2.1

1. I add User's JID to my contact-list
2. Authorization request is sent to User automatically
3. User grants authorization to me

4. My JID appears in User's contact list automatically
5. User's client opens dialog window to add my JID to his contact list again

6. Two ways are available:

1. If User adds my JID to his contact list again, then authorization request is sent automatically to me.
   
2. If User closes the dialog window, then User would stay unauthorized until he requests authorization manually and I authorize him.

> Can you get and post the Debug Window output of this happening from start to finish?

Adding TmpAcc@jabber.ru to TmpAcc@jabber.org causes duplication of TmpAcc@jabber.org in the TmpAcc@jabber.ru contact list. Log-file is attached.

[butters08]

Hey all, I'm using Pidgin 2.3.1 and I am still running into this problem. I am running my own ejabber server and it's in a school environment. It happens every time: Add buddy, buddy authorizes, I authorize buddy, now there are 2 of the buddy on my list and one of me on his. If I delete the duplicate, he is then unauthorized and if i try to authorize him again a duplicate appears once more. Is any work being done on this??

[downhillgames]

This longstanding bug needs to be found and squashed by any and all people who can find it and are capable of said squishage. Most annoying. (Still persists)

[froztbyte]

Something I've found, which does not exhibit similar behaviour as indicated in step 6 of comment 17, is like follows:

1) A adds B 2) B receives request, and pops up dialog 3) B edits 'Alias', clicks 'Accept' 4) A sees B come online, B sees 2x of A come online. Both "A's alias as entered" and "A's_address@…"

after a logout on B's side, B only sees "A's alias as entered" online, but the other entry still in the list.

I have downloaded the pidgin source, and I'm gonna see if I can find the exact b00g.

[chandru.in]

17 months and still no fix?

I experience the problem too. Pidgin version 2.4.1.

[deryni]

Various parts and incarnations of this (and similar) issues have been fixed at least twice, the problem is that there are a number of issues which look like this and are not and which look like mistakes and are not. Similarly, there are time when things like this look like they aren't mistakes or problems but are.

[Robby]

Try version 2.5.1.

[dhalik]

deryni:

We're also experiencing this issue with 2.5.1 on multiple different platforms at RU running against ejabberd 2.0.2. Other clients, Psi for example have not exhibited the behavior, so we're pretty sure it's pidgin specific. Here's a run down of what we see:

1) A adds B
2) B gets a popup and accepts
3) A sees B as online and receives the return confirmation request
4) A clicks the request and sees a second B become added

If I then go and check the server side roster I see only one A/B as expected, but yet A has two B's. Removing either B off of A's list results in a complete B removal off the server roster, but only one B client side.

Now B cannot see A as expected. A add's B again and after the same chain of events A ends up with THREE B's, with only one on A. :)

I can sends screen shots of this from multiple platforms and installs if you want. This is *not* happening because of alias changes. It is all from straightforward requests and adds, yet it doesn't happen on every person.

However, I do have a few people that I can consistently reproduce this with.

[darkrain42]

Deryni, I'm seeing this bug (more or less -- it's closer to #1089, but that was closed as a dup of this one).

JID A sends subscribe to JID B. Before B responds with subscribed, B sends subscribe to A, which triggers, for A, purple_account_request_authorization() with on_list false (incorrect, because a PurpleBuddy does exist for B, which eventually leads to Pidgin calling auth_and_add_cb (instead of auth_cb).

I'm attaching a one-liner.

[darkrain42]

Buddies with a subscription state of JABBER_SUB_PENDING are on_list

[datallah@…]

(In [98fe04f817ef415faebd3f7a38b7f0588c0b0cba]):
A fix from Paul Aurich for a long-standing XMPP issue with duplicate buddies. Fixes #479.

[schubert]

Although this ticket has been closed, I am still experiencing the duplicate buddy problem, even with the patch.

One case in which it occurs is the following:

Suppose A and B have each other in their buddy lists.

1) A removes B from A's buddy list. 2) Without B making any changes, A adds B back to A's buddy list, causing an authorization request to be sent to B. 3) B accepts the authorization request from A, but then is presented with the "Add Buddy" window. 4) If B now adds A, there will be two copies of A on B's list, since B never removed the initial instance. If B does not add A, the authorization will not go through.

[darkrain42]

So I have a new fairly braindead patch that should work.

Deryni: Basically, forget all of the checks -- determine that the user is "on list" by whether or not we found a PurpleBuddy; XMPP subscription status be damned.

The problem with this is that (given the example in #29), when B authorizes A, B does not request authorization from A (it must be done manually). I'm not sure I see decent solution to this.

Ideally, the authorization request wouldn't require the PRPL to determine "on list" status -- the UI would do that check when authorizing a request (there's a built-in race condition if I ignore an authorization request thing on the buddy list and add a buddy by hand). At that point in time, if there's a way for the GUI to determine subscription status (I haven't looked -- do the prpls expose this in a standard way?), it could change the current logic to something like:

if (onlist && we're not subscribed to contact's presence)
	request to subscribe to contact's presence
else if (!onlist)
	throw up the "add buddy" dialog like we do currently

[darkrain42]

It works, but it's not user friendly

[deryni]

The issue here is now an uncommon case which is caused by two "issues" in pidgin. One of which is an intentional decision that I don't think should change and one is an issue I think needs looking into.

The real issue is that pidgin allows someone to add identical duplicate buddies to an existing group, this should just not be allowed. I know of no protocol that allows it or what earthly purpose it might serve. Solving this would likely solve the main problem that is left here.

The second issue, the one that results from a more-or-less intentional decision (and which likely is only a problem because of the first issue), is that when we receive the subscription removal from the remote buddy we do not remove the local buddy from our buddy list. Doing so would remove any local alias, plugin settings, etc. for that buddy something which is not acceptable. This means that when the second auth request comes in we already have the buddy on the list but still need to ask for authorization and this results in the identical duplicate buddy issue above.

That being said, in this specific re-auth case the user can simply say no to adding the buddy and then right-click the offline buddy list entry for the buddy and re-request authorization from there. That should avoid the duplication problem and correctly request authorization to get things back to the correct state.

[shreevatsa]

Why not just *not* present the Add Buddy dialog, after asking/giving authorization, if the username is already on the buddy list?

[deryni]

Because being on the buddy list isn't enough for XMPP. As soon as you authorize someone to add you to their list they exist on your list (with a subscription of 'from'). Attempting to not present the add buddy dialog when it isn't appropriate (and making sure to present it when it is) is exactly what the code in the most recent patch was trying to make possible.

Pidgin used to never present the reciprocal Add Buddy dialog after someone added you to their list on XMPP, that caused lots of complaints so changes were made to fix that. The problem here is that pidgin, for some reason, isn't smart enough to re-use the existing buddy when one already exists, and I have no idea why it isn't, it should be. That's the duplicate buddy bug I think really needs fixing.

[darkrain42]

I just attached a patch that I think should fix this for Pidgin, Finch, and all the in-tree protocol plugins.

The fix for Pidgin and Finch is straightforward.

I audited all the prpls to ensure that the add_buddy functions could handle the situation in which a buddy is added when it is already in the group. This should function either as a no-op if the protocol does not support authorization (or we're already authorized) or it should (re-)request authorization from the contact. These clarifications don't actually constitute an API change because it is what happens currently, just in a more broken manner.

These in-tree prpls need some help from people more familiar with them:

Gadu-Gadu	I think it works?
MSN	I'm pretty sure it works properly. khc/QuLogic?
QQ	I think so? I had a lot of trouble following the logic in here
Sametime	I have no idea. I think it depends on how mwAwareList_addAware works
TOC	It looks like it...also, I don't think anyone cares ;)
Yahoo	I think so?

I'm fairly certain about bonjour, irc, jabber, myspace, null, oscar, and simple.

[darkrain42]

Sametime/Meanwhile is actually OK. mwAwareList_addAware only adds non-dupes:

  /* for each awareness id:
     - if it's already in the list, continue
     - if it's not in the service list:
       - create an awareness
       - add it to the service list
     - add this list to the membership
     - add to the list
  */

[chemistrydioxide]

ArcFi?: Your screenshots (especially no. 4 and 5) do not show duplicate buddies.

Jabber IDs are case-sensitive, i.e. asdf@… ≠ AsDf?@jabber.example.com

So you have two different users with different JIDs on your list.

I wonder why both of these two list entries are showing your status correctly since one of the two JIDs should be wrong.

[deryni]

The user portion of the jid is subject to the Nodeprep profile of Stringprep, a profile which to the best of my knowledge is in fact not case sensitive and is in fact not even character sensitive (that is multiple characters that look similar map to the same result).

[schubert]

I have tried the new patch but I still have the same duplicate buddy issue with jabber in the scenario I described earlier:

A and B have each other in their buddy lists.

1) A removes B from A's buddy list.
2) Without B making any changes, A adds B back to A's buddy list, causing an authorization request to be sent to B.
3) B accepts the authorization request from A, but then is presented with the "Add Buddy" window.
4) If B now adds A, there will be two copies of A on B's list, since B never removed the initial instance. If B does not add A, the authorization will not go through.

[darkrain42]

Updated patch (changed section is in gtkblist.c)

[darkrain42]

Replying to schubert:

I have tried the new patch but I still have the same duplicate buddy issue with jabber in the scenario I described earlier: A and B have each other in their buddy lists. 1) A removes B from A's buddy list.
2) Without B making any changes, A adds B back to A's buddy list, causing an authorization request to be sent to B.
3) B accepts the authorization request from A, but then is presented with the "Add Buddy" window.
4) If B now adds A, there will be two copies of A on B's list, since B never removed the initial instance. If B does not add A, the authorization will not go through.

You're correct; it doesn't work properly if, in step 4, the not-authorized copy of the buddy is in the "Buddies" group and you do not specify a group in which to add the buddy. The code in libpurple will default this to "Buddies", but the gtkblist.c checks in my patch won't find that existing PurpleBuddy? ( purple_find_buddy_in_group(account, who, group == "" or group == NULL) will return NULL).

I attached an updated patch that will re-use any existing PurpleBuddy? if no group was specified, which should work.

[chemistrydioxide]

deryni: I should have looked this up in RFC 3920 before posting here. You are right.

Replying to deryni:

The user portion of the jid is subject to the Nodeprep profile of Stringprep, a profile which to the best of my knowledge is in fact not case sensitive and is in fact not even character sensitive (that is multiple characters that look similar map to the same result).

[darkrain42]

Will some developers take a look at MSN, Yahoo, and QQ and make sure that, when calling the buddy_add prpl function, if the buddy already exists in the specified group, it functions as a no-op or it re-requests authorization from the buddy? (see attached patch and comments 35 and 36 for details)

I'd like to get this into 2.5.5 if possible :)

[darkrain42]

Ticket #8511 has been marked as a duplicate of this ticket.

[paul@…]

(In [f8e29008581f125525301f7a98874c63847b2c29]):
Changelog the im.pidgin.cpw.darkrain42.buddy-add branch.

Also fixed some whitespace in ChangeLog.API.

Fixes #479. For good, I hope.