Original bug report: https://bugzilla.gnome.org/show_bug.cgi?id=666466 """ Steps : 1. Set up a Jabber account (let say adressname@blabla.net). 1bis. In the "personal information" window of the account, set a nickname 2. Join a Jabber chatroom 3. Make it a favorite 4. Activate auto-join for this chatroom At this point, two possibilities : a. If you join manually the chatroom using the menu, and you have the nickname set up at step (1) correctly. Everything is fine. b. If you start Empathy (previously closed), the auto-join makes you join the channel. BUT the nickname you have is not the nickname set at step (1), but "adressname". Note that it's not always the case, but almost all the time. And I had this problem as well on previous Fedora versions. Thanks in advance =) """ Empathy is just requesting the MUC channel without specifiying any nickname so that's probably a race in Gabble.
This happens here too, but I think it is not related to auto-joining a groupchat. I was just able to reproduce this issue without joining a groupchat on startup/connect. Components/versions: telepathy-glib-0.17.4 telepathy-gabble-0.15.2 telepathy-mission-control-5.10.1 I used mc-tool to reproduce this issue: elias@moria ~ % mc-tool show gabble/jabber/ep_40company_2ecom0 Account: gabble/jabber/ep_40company_2ecom0 Display Name: ep@jabber.company.com Normalized: ep@jabber.company.com Enabled: enabled Icon: im-jabber Connects: automatically Nickname: ep@jabber.company.com Service: jabber Presences: Automatic: available (2) "" Current: available (2) "" Requested: available (2) "" Changing: yes (GStrv) fallback-socks5-proxies = [""] (uint) port = 5223 (bool) old-ssl = true (string) password = nothing-to-see-here:) (string) resource = Laptop (string) server = jabber.company.com (string) account = ep@jabber.company.com elias@moria ~ % mc-tool nick gabble/jabber/ep_40company_2ecom0 ep elias@moria ~ % mc-tool show gabble/jabber/ep_40company_2ecom0 Account: gabble/jabber/ep_40company_2ecom0 Display Name: ep@jabber.company.com Normalized: ep@jabber.company.com Enabled: enabled Icon: im-jabber Connects: automatically Nickname: ep Service: jabber Presences: Automatic: available (2) "" Current: available (2) "" Requested: available (2) "" Changing: yes (GStrv) fallback-socks5-proxies = [""] (uint) port = 5223 (bool) old-ssl = true (string) password = nothing-to-see-here:) (string) resource = Laptop (string) server = jabber.company.com (string) account = ep@jabber.company.com elias@moria ~ % mc-tool disable gabble/jabber/ep_40company_2ecom0 elias@moria ~ % mc-tool enable gabble/jabber/ep_40company_2ecom0 elias@moria ~ % mc-tool show gabble/jabber/ep_40company_2ecom0 Account: gabble/jabber/ep_40company_2ecom0 Display Name: ep@jabber.company.com Normalized: ep@jabber.company.com Enabled: enabled Icon: im-jabber Connects: automatically Nickname: ep@jabber.company.com Service: jabber Presences: Automatic: available (2) "" Current: available (2) "" Requested: available (2) "" Changing: yes (GStrv) fallback-socks5-proxies = [""] (uint) port = 5223 (bool) old-ssl = true (string) password = nothing-to-see-here:) (string) resource = Laptop (string) server = jabber.company.com (string) account = ep@jabber.company.com
Also happening to me on Archlinux [dam@dalexandre-linux ~]$ pacman -Qs telepathy local/empathy 3.12.7-2 (gnome) A GNOME instant messaging client using the Telepathy framework. local/telepathy-farstream 0.6.2-2 A telepathy-backend to use stream engine. local/telepathy-gabble 0.18.3-1 (telepathy) A Jabber/XMPP connection manager for Telepathy local/telepathy-glib 0.24.1-1 GLib bindings for the Telepathy D-Bus protocol local/telepathy-idle 0.2.0-1 (telepathy) An IRC connection manager for Telepathy local/telepathy-logger 0.8.1-1 Telepathy framework logging daemon local/telepathy-mission-control 5.16.3-1 A Telepathy component providing abstraction of some of the details of connection manage
Here's my debugging so far: The muc channels are joined before the roster is downloaded; i.e. I'm seeing these function calls in this order under gdb: - connector_connected - gabble_muc_channel_constructed (repeated one time per auto-joined channel) - roster_received_cb For each channel, when create_room_identity calls _gabble_connection_get_cached_alias, there is no alias set (because the remote roster has not yet been fetched), and it does not manage to fall back to the locally set alias as I would have expected.
I can also confirm the "not always the case" bit of the original report: when repeatedly disabling/enabling my account, occasionally my alias does show in the MUC rooms - I guess because the roster wins the race sometimes. I can't confirm the mc-tool steps from comment #1 - that did not reset the Nickname for me, but it's quite possible something changed since 2012. Anyway, I think the "Nickname" property is quite disconnected from the MUC alias at this point. My first thought was to track down why the connection manager does not get the "alias" property set, but that brings in other parts of Telepathy. A better fix might be to wait for the roster before auto-joining MUC rooms - but I'm not sure if the roster is fetched synchronously, i.e. how long could we be waiting?
(In reply to Tim Retout from comment #4) > My first thought was to track down why the connection manager does not get > the "alias" property set, but that brings in other parts of Telepathy. Specifically mission-control - the nickname only gets sent in mcd_account_connection_ready_cb, which might be *after* the new connection is created? I doubt the changes in bug #55668 affected this behaviour.
(In reply to Tim Retout from comment #5) > (In reply to Tim Retout from comment #4) > > My first thought was to track down why the connection manager does not get > > the "alias" property set, but that brings in other parts of Telepathy. > > Specifically mission-control - the nickname only gets sent in > mcd_account_connection_ready_cb, which might be *after* the new connection > is created? I doubt the changes in bug #55668 affected this behaviour. Well looking at mcd_account_connection_ready_cb there's that big FIXME saying they want to trust the server side alias because not every protocol has a locally defined alias. It looks like the WockyMuc object has nickname property, but I'm not sure how it gets set. I wonder if they were just being simple since both the self contact and roster contacts may be being coming from the server as vcard objects, and it looked like roster managing code was triggering the nickname-update signal.
Dug further. in telepathy-gabble/src/muc-channel.c:405 this call gets the correctly formatted MUC room JID <room@server/desired_user_nick> const gchar *room_jid = tp_handle_inspect (contact_handles, self_handle); tp_handle_inspect is from telepathy-glib, I know in general telepathy is designed to use handles to refer to contact information, currently I don't know where the room_jid string is being attached to the contact handle.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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.freedesktop.org/telepathy/telepathy-gabble/issues/204.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.