Chat list shows a room JID fragment instead of the group name #21

New issue

Open

opened 2026-11-07 08:55:18 +00:00 by fmodf · 1 comment

fmodf commented

2026-11-07 08:55:18 +00:00

Moved from another-im/anotherim-swift#24, reported by @asemeniv on 2026-11-06. The attachments are re-uploaded below.

Chat list shows a room JID fragment instead of the group name
Problem
When a room bookmark has an empty name, the chat list and the group header use different fallback logic.

The group header displays the actual room name, while the chat list displays the part of the room JID before @.

Preconditions
User testman421 is a member of “New 86 14102026 1”.
The room bookmark received from the server has an empty name: "name": "".
Steps to reproduce
Open the Chats tab on iPhone 13.
Find the group “New 86 14102026 1”.
Open the group and check its header.
Actual result
Chat list: qlwhfw7f7fue
Group header: New 86 1410…
Expected result
The chat list and group header should display the same group name.

Suggested direction
Use the room name as a fallback when the bookmark name is empty, rather than displaying a fragment of the room JID.

Note: The requirements specification confirms that a MUC has a name but does not explicitly define how it should be displayed. This issue is therefore a recommendation for consistent UI behavior.

Analysis (anotherim-swift, 2026-11-07)

The report was made on build 89, where the group header took the room's disco name. On current master the chat list, the header and the details page all take name from libtacky's chatlist entry, so with an empty bookmark name they all show the JID's local part.

chatlist.tcl MakeEntry (:71, :654) names a room only by its bookmark.
The room's disco name (MucRoomInfo.name) is kept only in memory, Rooms($roomJid) info (muc.tcl :487), and never reaches a row.
Bookmarks are written with no name by muc accept_invite (muc.tcl :1712) and by hosts that join with bookmarks join, which is the likely source of the empty name.

Proposed fix in libtacky: when a room's bookmark name is empty, MakeEntry falls back to the room's disco name (kept with the room as KindOf is), and the entry is emitted again on muc <RoomInfo>, as it is on muc <Kind> (chatlist.tcl :174). Possibly also: accept_invite/bookmarks join fill the bookmark's name from disco#info when they have it.

> Moved from another-im/anotherim-swift#24, reported by @asemeniv on 2026-11-06. The attachments are re-uploaded below. Chat list shows a room JID fragment instead of the group name Problem When a room bookmark has an empty name, the chat list and the group header use different fallback logic. The group header displays the actual room name, while the chat list displays the part of the room JID before @. Preconditions User testman421 is a member of “New 86 14102026 1”. The room bookmark received from the server has an empty name: "name": "". Steps to reproduce Open the Chats tab on iPhone 13. Find the group “New 86 14102026 1”. Open the group and check its header. Actual result Chat list: qlwhfw7f7fue Group header: New 86 1410… Expected result The chat list and group header should display the same group name. Suggested direction Use the room name as a fallback when the bookmark name is empty, rather than displaying a fragment of the room JID. Note: The requirements specification confirms that a MUC has a name but does not explicitly define how it should be displayed. This issue is therefore a recommendation for consistent UI behavior. --- ## Analysis (anotherim-swift, 2026-11-07) The report was made on build 89, where the group header took the room's disco name. On current master the chat list, the header and the details page all take `name` from libtacky's `chatlist` entry, so with an empty bookmark name they all show the JID's local part. - `chatlist.tcl` `MakeEntry` (:71, :654) names a room only by its bookmark. - The room's disco name (`MucRoomInfo.name`) is kept only in memory, `Rooms($roomJid) info` (`muc.tcl` :487), and never reaches a row. - Bookmarks are written with no name by `muc accept_invite` (`muc.tcl` :1712) and by hosts that join with `bookmarks join`, which is the likely source of the empty name. **Proposed fix in libtacky:** when a room's bookmark name is empty, `MakeEntry` falls back to the room's disco name (kept with the room as `KindOf` is), and the entry is emitted again on `muc <RoomInfo>`, as it is on `muc <Kind>` (`chatlist.tcl` :174). Possibly also: `accept_invite`/`bookmarks join` fill the bookmark's name from disco#info when they have it.

image (2).png

195 KiB

bug_89_chatlist_room_name_shows_jid_localpart.zip

213 KiB

fmodf referenced this issue from another-im/anotherim-swift

2026-11-07 08:55:20 +00:00

Chat list shows a room JID fragment instead of the group name #24

ann referenced this issue from a commit

2026-11-07 17:20:10 +00:00

chatlist: a row follows message <Expired> and a tail's <Removed> (#23); a room whose bookmark names none is named by its disco#info identity, kept as module state muc_name and told as muc:<Name> (#21)

ann referenced this issue from a commit

2026-11-07 22:27:34 +00:00

HANDBOOK: regenerated for the #21 and #22 schema changes (ChatEntry, roster <Subscribe> -reason)

ann referenced this issue from a commit

2026-11-07 22:27:34 +00:00

S5: captcha: check a challenge's inline images as forms elsewhere do

ann commented

2026-11-07 23:13:12 +00:00

Owner

Fixed in libtacky v1.2.1 (https://dev.another.im/another-im/libtacky/releases/tag/v1.2.1): a room whose bookmark has no name is now named from its disco#info name instead. That name is kept across restarts (stored as muc_name) and used both for the chat list entry and for the room's name in a PM from one of its occupants. It is re-emitted whenever it changes (chat list row updated as muc:<Name>).

Please check with v1.2.1 or newer.

Fixed in libtacky v1.2.1 (https://dev.another.im/another-im/libtacky/releases/tag/v1.2.1): a room whose bookmark has no name is now named from its disco#info name instead. That name is kept across restarts (stored as `muc_name`) and used both for the chat list entry and for the room's name in a PM from one of its occupants. It is re-emitted whenever it changes (chat list row updated as `muc:<Name>`). Please check with v1.2.1 or newer.