Bug 45395

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.