The room topic doesn't support aliases or user IDs.

[pixlwave]

Steps to reproduce

1. Open the room details for a room that you're admin.
2. Add a topic such as This is #room:example.com and @user:example.com is the admin..

Outcome

What did you expect?

To see the topic This is #room:example.com and @user:example.com is the admin..

What happened instead?

The topic is shown as This is and is the admin..

The HTML parser is likely adding attachments for pills but there isn't support for pills in that view. Maybe we should add some fallback text if that's possible 🤔.

Your phone model

MacBook Pro

Operating system version

macOS 26.5

Application version

26.06.0 TestFlight

Homeserver

matrix.org

Will you send logs?

No

[mredig]

So I'm looking into this. It seems like the simplest approach is to just replace the MentionBuilder in RoomFlowCoordinator with

attributedStringBuilder: AttributedStringBuilder(mentionBuilder: PlainMentionBuilder()),

however, while doing that now renders the text appropriately, it has two side effects:

1. it initially draws the text in a uniform color, but as soon as it's tapped the links for the alias and user turn blue (I'm uncertain if it's a project defined blue or the default, iOS link blue).
2. tapping the links is broken if the linked data is invalid (such as the provided sample data). it then breaks all buttons on the screen other than the back button.
   • 2.5 linking to ANOTHER room or user results in a navigation hierarchy where the linked item is a child of this one. That seems counter intuitive and confusing. Additionally, linking to the current room resolves to doing nothing, and linking to a user takes you to the user's profile, with context of whether they are a member of the room or not.

An alternative to this is to just render the string in plaintext, ignoring the attributed string links, etc. It really just depends on the intent of this feature.

I'll be happy to provide a fix, given proper guidance on what's desired.

[pixlwave]

Thank you! Yes that definitely sounds like the correct approach to me using a string builder with an appropriate configuration for this specific screen 👍

1. The first tap expands the topic and makes any links tappable (however the expanding isn't always obvious when testing a short topic). It should be using our .compound.textLinkExternal colour which is blue, but a fairly dark shade of blue.
2. Do you know what happens here? It should push the JoinRoomScreen for anything that the user isn't a member of. Maybe it gets stuck looking up the alias -> room ID? I wonder if the same happens on the RoomScreen too? Either way, I wouldn't necessarily call this a blocker, it can be handled as a separate bug if needs be.
   • 2.5 This is how all permalinks work within the app so that the back button always takes you back to the place where you tapped the link. Only external links clear the navigation stack.

An alternative to this is to just render the string in plaintext, ignoring the attributed string links, etc. It really just depends on the intent of this feature.

The problem here would be that any HTML links (which are common in the topic and the main reason why we're parsing this string) would no longer be tappable so rendering in plaintext won't be enough I'm afraid.