Fixes https://github.com/vector-im/riot-web/issues/14198
For both, the decision has been made to not have a context menu pending further considerations of where invites should (and should not) be. Likely this will be dealt with in FTUE Notifications.
For example, if you only have 3/10 rooms required for the default then resize smaller, we should have a 'show more' button.
This works by changing the rendering to be slightly more efficient and only looping over what is seen (renderVisibleTiles(), using this.numTiles in place of tiles.length) and using a new setVisibleTilesWithin() function on the layout. Previously resizing the 3/10 case would be setting visibleTiles to ~8 instead of ~1 like it should (because the getter returns a default).
`setKnownRooms` is called to regenerate the room list, and if we don't take the sticky room out of the equation we end up with the room being duplicated. So, to make this easy, we simply remove the sticky room and handle it after the fact.
This small check just ensures that we aren't about to blindly accept that the calling code knows what it is doing. There are some unknown cases where NewRoom gets fired for rooms we already know about, so in those cases we just change it to a PossibleTagChange which is what the caller likely intended.
Many of the edge cases are unknown, though this can happen for an invite being accepted (for example). It's easier to handle it here instead of tracking down every single possibility and fixing it higher up.
When a new room is added there's a fairly good chance that the other events being dispatched will happen in the middle of (for example) the room list being re-sorted. This commit wraps the entire handleRoomUpdate() function for the underlying algorithms in a lock so that if we're unlucky enough to get an update while we're sorting (as the ImportanceAlgorithm splices out what it is sorting) we won't scream about invalid index errors.
We have to do a bit of a dance to return the sticky room to the list so we can remove it, if needed, and ensure that we generally swap the rooms out of the list.
It is possible for your read marker to be set to an event without a tile (like a
reaction). We would still render the read marker at the position of those events
in the timeline, even though there's no matching tile, which breaks a core
assumption of jump to read marker path: it assumes that if the read marker node
is present in the DOM, then there must also be an event tile with a scroll token
matching the event ID.
This fixes the situation by setting a scroll token on the read marker so it can
always be scrolled to, no matter what kind of event it might represent.
Fixesvector-im/riot-web#10975
Jeff Huang