Currently, any error in the `GroupStore`s several requests can cause the whole
`GroupView` component to hide and be mark the group as failed to load.
Since it is known that group members may fail to load in some cases, let's only
show failed to load for the whole group when the summary fails.
This also strengthens the `GroupView` test by ensuring we wait for multiple
updates for checking results.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
Not doing so results in the RoomListStore tracking stale data when the user reads messages on another device. The visual effect of this is rooms being incorrectly pinned in places they shouldn't be, such as the top of the list. This also fixes another visual bug where rooms don't move down once their timelines are read. This second issue is mot prominent when multiple rooms have been pinned to the top, and the middle one is read ahead of the others - it'll stick around until some other condition decides to wipe the room's cached state.
Fixes https://github.com/vector-im/riot-web/issues/7653
This is more reliable with LL enabled as the syncing user is
only known when it was active in the current timeline
or when the members have been loaded
as everything listens to the dispatcher, dispatching an action can be quite slow,
especially when only matched in one listener, and the rest all having to be called
to just say "no, thanks". This is especially the case for the RoomMember.membership
event being put on the dispatcher, as there can be thousands of these events
when the room members are loading.
Since the RoomMember.membership action is only used on one place,
and only for the syncing user, change it to just that and only dispatch
in that case. This saves 100-300ms when setting the OOB members in
a big room (7000k members)
Maybe later on we can back this by room.getMyMembership() and avoid the
listener even...
Fix Riot's behaviour with room tags after my cleanup in
https://github.com/matrix-org/matrix-doc/pull/1457 . Although, reading
it again, it's not clear how you're supposed to tell the difference
between a reverse-dns tag name and a legacy freeform text tag
(contains a '.'?) - I've left it detecting these as freeform text
for now.
ActiveWidgetStore is now reponsible for removing the current
persistent widget from the store if it's been removed from whatever
room it was in. As per comment, this leaves us with the store updating
itself in this case but in all other cases, views call setters on the
store to update its state. We should make it so the store keeps itself
up to date and views aren't responsible for keeping the store up to date.
The store now emits events so it can notify PersistentApp when it changes.
Fixes https://github.com/vector-im/riot-web/issues/7076
As per https://github.com/matrix-org/matrix-doc/issues/1354
This is whitelisted to only jitsi widgets for now as per comment,
mostly because any widget that we may make always-on-screen we need
to preemptively put in a PersistedElement container, which is
unnecessary for any other widget.
Apologies that this does a bunch of refactoring which could have
been split out separately: I only discovered what needed to be
refactored in the process of doing this.
Fixes https://github.com/vector-im/riot-web/issues/6984
* Show a spinner while we wait for widgets to be deleted
* Hide widgets while they're pending deletion
* Don't put another jitsi widget into the room if there's already
one pending
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
Take a step closer to a flux-like architecture for group data, for
the purposes of providing features that require it.
Now the app has a single GroupStore that can be poked to fetch
updates for a particular group.
using a FIFO queue.
This is needed in order to lower the priority of getting group
state and prioritise everything else, namely initial sync.
It should be noted that this by no means guarantees that the
first incremental sync will happen sooner; the client could
end up doing some other requests first instead.
For each successful request of a group profile, we previously
emitted an `updateGroupProfile` event per caller of
`getGroupProfileCached`. This is sub-optimal because only a single
event emit is required to update the views listening.
It's possible that this was enabling some race to cause a memory
leak but this is not certain, hence the extra logging for future
debugging.
Previously we assumed that a decrypted event has a room_id
but this isn't necessarily true for to_device events.
It makes sense to ignore events that aren't associated with
rooms anyway given that the list we're updating only contains
rooms!
To make sure that we handle rooms that our
client has not seen previously, we regenerate
the room list when the room is stored -
which is indicated by the js-sdk by the
Room event.
so that we can do reorderings of lists ordered by most recent event.
No optimisations here; we only update for timeline events
on live timelines that could update the "unread count".
Actually fixes vector-im/riot-web#6135 unlike #1748, which
incorrectly assumed that custom tags would be included in
listOrders.
This fix makes sure that the `default` case in the `switch`
is actually used.
