After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644472 - Race in Block Contact GtkCheckMenuItem
Race in Block Contact GtkCheckMenuItem
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: Chat
2.33.x
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
Depends on: 618787
Blocks:
 
 
Reported: 2011-03-11 05:57 UTC by Danielle Madeley
Modified: 2018-05-22 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Danielle Madeley 2011-03-11 05:57:39 UTC
The GtkCheckMenuItem for block contact doesn't always show the current block state of a contact due to a race between when the menu is rebuilt and when the asynchronous operation for blocking completes.

This bit of code is useless:

        /* update the toggle with the blocked status */
        block_signal++;
        gtk_check_menu_item_set_active (item, blocked);
        block_signal--;

Because the menu rebuilds almost immediately at which point empathy_contact_list_get_blocked() probably still returns the old value.

~

This should probably be fixed by creating a "blocked" property on EmpathyContact that updates in response to ::group-members-changed on the 'deny' channel. We can then bind the value of the "blocked" property to the "active" property on the GtkCheckMenuItem. And make ::toggled not do anything if the contact is already blocked/unblocked.
Comment 1 GNOME Infrastructure Team 2018-05-22 14:40:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/350.