Opened 8 years ago

Last modified 7 years ago

#14309 new defect

Pidgin doesnt remember me in created group after program restart

Reported by: LukynZ Owned by: deryni
Milestone: Component: XMPP
Version: 2.8.0 Keywords:
Cc:

Description

  1. add yourself to xmpp account
  2. create new group, for example named Me
  3. move yourself to Me
  4. restart pidgin

After restart group Me is empty and I am moved to base xmpp group. Others accounts moved to Me stay there after restart.

Attachments (2)

patch-blist_add_contact-order_of_updates-2.10.0.diff (3.1 KB) - added by dustin 7 years ago.
Patch to fix a data inconsistency in purple_blist_add_contact(), which made purple_find_buddies() return incomplete list of buddies.
xmpp-blist_add_contact-order_of_updates-v2.diff (3.9 KB) - added by dustin 7 years ago.
Former patch with some simplifying modifications.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 8 years ago by dustin

I can confirm this. More generally, the first xmpp buddy moved to an otherwise empty group will be ignored.

Looks like this is because purple_find_buddies() and purple_find_buddy() in libpurple/blist.c require a group node entry that already has a child node. When moving an entry to an empty group, these functions return NULL to jabber_roster_group_change().

--- blist.c	2011-06-16 18:03:01.000000000 +0200
+++ blist.c.marked	2011-06-19 17:32:58.000000000 +0200
@@ -2438,12 +2438,12 @@
 
 	hb.account = account;
 	hb.name = (gchar *)purple_normalize(account, name);
 
 	for (group = purplebuddylist->root; group; group = group->next) {
0		if (!group->child)
0			continue;
 
 		hb.group = group;
 		if ((buddy = g_hash_table_lookup(purplebuddylist->buddies, &hb))) {
 			return buddy;
 		}
@@ -2490,12 +2490,12 @@
 
 		hb.name = (gchar *)purple_normalize(account, name);
 		hb.account = account;
 
 		for (node = purplebuddylist->root; node != NULL; node = node->next) {
0			if (!node->child)
0				continue;
 
 			hb.group = node;
 			if ((buddy = g_hash_table_lookup(purplebuddylist->buddies, &hb)) != NULL)
 				ret = g_slist_prepend(ret, buddy);
 		}

For ICQ entries, there is no such problem.

Changed 7 years ago by dustin

Patch to fix a data inconsistency in purple_blist_add_contact(), which made purple_find_buddies() return incomplete list of buddies.

comment:2 Changed 7 years ago by dustin

(IMHO, this is a minor bug that can easily be worked around, so it may be better to consider the patch after Pidgin 3.0 is out.

There's another patch in #14610 which seems to cure a more serious problem with contacts disappearing altogether, that could be used in the meantime. (The two patches are incompatible, though.)

Hi,

in [blist.c] purple_blist_add_contact(), moving a buddy to another group currently takes place in this order:

  • contact is unlinked from purplebuddylist
  • for each buddy:
    • buddy is removed from old and added to new group in hash_tables
    • jabber_roster_group_change() is called via serv_move_buddy()
  • after that contact is relinked to purplebuddylist in new group + ui_ops

At the point where serv_move_buddy() is called, the buddy's cnode is no longer registered in any group. In case the new group was empty, purple_find_buddies() will not find any cnode in the new group, so there's no lookup for the moved buddy.

The patch changes the order to:

  • for each buddy:
    • jabber_roster_group_change() is called via serv_move_buddy()
    • buddy is removed from old and added to new group in hash_tables
  • contact is unlinked from purplebuddylist
  • after that contact is relinked to purplebuddylist in new group + ui_ops

... so when purple_find_buddies() is called, the moved buddy will be found in the old group.

comment:3 Changed 7 years ago by dustin

The former patch with slight modifications:

Unregistering buddy from the hash tables only has to be done in the if branch.

For the else case (buddy already exists in group), purple_blist_remove_buddy() will take care of that anyway.

Changed 7 years ago by dustin

Former patch with some simplifying modifications.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!