Fix active room not moving in the room list after new activity

[borzov]

Problem

When a new message arrived in the currently open room, or when I sent a message in that room myself, the room list did not immediately reorder.

In practice, the active room could stay in its previous position until I clicked into another room. That made the room list feel stale and out of sync with the actual conversation activity.

Root cause

There were two separate issues contributing to this:

1. The room list view model kept the active room "sticky" at its previous index, which could mask legitimate reorder updates.
2. Recency sorting could prefer a stale bumpStamp over newer activity already present in the live timeline, so the room's effective sort timestamp was not always the freshest available signal.

Fix

This change removes the sticky positioning behaviour for the active room in the new room list view model and updates recency sorting so that it uses the freshest timestamp available instead of blindly trusting bumpStamp.

As a result, when the active room receives a message or when I send one there myself, the room is reordered immediately and the room list stays in sync with actual room activity.

Why this matters

This is a small change in code, but it fixes a very visible day-to-day UX issue.

The room list is one of the main navigation surfaces in Element. If it does not react immediately to incoming or outgoing activity, it feels laggy and forces extra clicks just to refresh the user's view of what is active right now. This change makes that behaviour feel much closer to what users expect from modern chat clients.

Additional context

This PR includes unit test updates covering both the room list view model behaviour and the recency timestamp selection logic.

All automated and manual checks were completed before opening this PR, and the updated build was manually verified by the author.

Notes: Fix a bug where the active room could remain in its previous position in the room list until the user switched rooms, instead of moving immediately when new activity happened.

[florianduros]

Hello,

This is not a bug but an accessiblity feature. We introduced this "sticky position" behavior in the room list to improve the overall accessiblity of the room list. Aka, don't change the position of the current selected room in order to not confuse users with disability or using voice over software.

• https://www.w3.org/WAI/WCAG21/Understanding/focus-order.html
• https://www.w3.org/WAI/WCAG21/Understanding/on-input.html

I'm putting product and design in the loop but afaik this is a behavior we are keen to keep.

[borzov]

Thanks for the detailed feedback, @florianduros and I completely understand the point. Looking at the code, I can see this behavior is clearly intentional: the active room is deliberately kept "sticky" to avoid the list jumping around while you're reading. That's a reasonable design decision on its own.

That said, I'd like to share some real-world context. Our company has recently started using Element more actively, and so have many of our colleagues and clients — often as an alternative communication channel alongside Telegram and WhatsApp. Almost universally, the first thing people notice is that the room list doesn't reorder when you're in an active conversation. Coming from other messengers, it feels unexpected and disorienting. In our internal chats, it's been brought up multiple times as an annoying "bug" even though, as we now know, it's not technically a bug at all.

I think this is a case where the industry standard has shaped user expectations so strongly that deviating from it even with good intentions ends up feeling like a flaw rather than a feature. Telegram, WhatsApp, Signal, Slack — they all reorder the list in real time, including for the active conversation. Users have internalized this pattern deeply.

I'm not here to push back on the design philosophy. I genuinely appreciate how thoughtfully Element is built and how responsive the team is to community contributions. But I do think this particular behavior deserves a second look from a UX perspective.

If keeping the current behavior as the default makes sense for some use cases, perhaps a middle ground would be to expose this as a user-configurable option, letting people choose whether the active room stays pinned or moves with activity. That way, both preferences are respected.

Thanks again for your time and for reviewing this!