Does a thirdparty protocol lookup to the homeserver to get the
corresponding native/virtual user for a matrix ID. Stores the
mappings in room account data. Involves some slightly nasty workarounds
for that fact that room account data has no local echo.
If your homeserver is configured with an experiment `widget_build_url`, this
will take over the functionality of the call buttons and turn them into a
general widget installer.
Seems to be that as part of the layout work the timing sequence for when `.getRoom().widgets` will work changed. We can get around this with `initIfNeeded` which will no-op in the worst case.
This also includes a copy change to make ended conferences stop lying about where to find the widget. This is work towards https://github.com/vector-im/element-web/issues/15739
The accompanying element-web PR with the config documentation should
explain what this is & why. Internally, this breaks the assumption
that call.roomId is the room that the call appears in for the user.
call.roomId may now be a 'virtual' room while the react SDK actually
displays it in a different room. React SDK always stores the calls
under the user-facing rooms, and provides a function to get the
user-facing room for a given call.
Note that this ditches all previously set width values, however this is probably acceptable for now. Trying to remain backwards compatible gets tricky on top of already tricky code, and the impact of Element forgetting widths is not as severe as forgetting which widgets were/are pinned.
Turns out that we were obliterating the entire store of widgets each time we loaded a widget, which is less than helpful. This commit fixes that.
This commit also improves the cleanup of the pinned event object to remove unpinned widgets, reducing accumulation over time.
Fixes https://github.com/vector-im/element-web/issues/15948
This is for https://github.com/vector-im/element-web/issues/15705https://github.com/matrix-org/matrix-react-sdk/pull/5459 was unable to track down all the instances of where the issue happens, so this commit tries to do a more complete job.
Specifically, this replaces the getRoomId() function given widgets cannot reliably be referenced by widget ID in this way, and the store has been updated to handle a more unique widget ID for the store (just in case).
Further sanity checking has also been added to ensure that we are at least returning a valid result.
This should also help https://github.com/vector-im/element-web/issues/15705 by either implicitly fixing the problem, causing chaos as described in the issue, or by forcing a crash to identify the problem more easily.
This should alleviate https://github.com/vector-im/element-web/issues/15705 from happening, though the cause is still unknown.
Requiring a room ID is safe for this because only room widgets can be pinned, and widget IDs are not globally unique which means from a logical standpoint the contract still makes sense here.
Fixes https://github.com/vector-im/element-web/issues/15745
This was surprisingly easy given the number of errors I remember last time, but here it is. This also includes an over-engineered VisibilityProvider with the intention that it'll get used in the future for things like Spaces and other X as Rooms stuff.
The security key naming/practice was misguided, so let's call it what it is (a settings key) and abstract away the complexity to a new store.
Fixes https://github.com/vector-im/element-web/issues/15820 while we're here.
The "remember my selection" option wasn't working because the `missing` set still included the approved permission. Solution: remove it from `missing`.
The customisation point is to allow forks to change which widgets get which additional capabilities dependent on their own rules.
Following https://github.com/matrix-org/matrix-react-sdk/pull/5385, it is now possible for a widget to request these capabilities without being a video conference or sticker picker. This commit actually enables this support for those kinds of widgets.
This commit also fixes an issue in the URL templating where some variables might get set to 'undefined' - this appears to be a scoping issue, so StopGapWidget now stores the definition alongside the superclass.
Fixes https://github.com/vector-im/element-web/issues/15001
TypeScript helpfully pointed me towards this dead code, which has been floating
around unused for a while. If we want to bring back ILAG in the future, we can
always revive it from history.
Prototype behaviour:
* If you can't create a room in the community, say so.
* The UX for this could probably be improved, but for now the intention is to not break muscle memory by hiding the create room option.
* If you can't change settings in the community, or can't invite people, don't show those respective options.
* Breaking muscle memory here is moderately okay.
Behaviour constraints:
* If you're not in the conference, use a grey button that does nothing.
* If you're in the conference, show a button:
* If you're able to modify widgets in the room, annotate it in the context of ending the call for everyone and remove the widget. Use a confirmation dialog.
* If you're not able to modify widgets in the room, hang up.
For this we know that persistent Jitsi widgets will mean that the user is in the call, so we use that to determine if they are actually participating.
This is a step towards https://github.com/vector-im/element-web/issues/13430
Since we've stored the invite, we can send the user to it once they reload the page or revisit Element. We currently only support one invite at a time, but this should be fine for most cases.
We only do this restoration if the next screen isn't set to avoid breaking the user out of an expected flow.
As an added touch, this also ensures that the email address is pre-filled on the registration page if needed, just in case the user refreshes before getting to the submit button.
As part of new device verification, we were waiting for "cross-signing ready"
which means _both_ the public keys are trusted by this device _and_ private keys
are available. There's no guarantee that the private keys will ever arrive, so
it's too strict to wait for this as a blocking flow. This relaxes things to wait
only for the current device to trust public keys.
Fixes https://github.com/vector-im/element-web/issues/14970
Ideally this would open up the group members panel, but that's exceedingly difficult. Instead, we switch to the general chat and rename the button to be a bit more helpful.
Fixes https://github.com/vector-im/element-web/issues/14848
When we're filtering the sticky room will be excluded from the filtered set, and thus won't even appear in the `getOrderedRoomsWithoutSticky()` result. Further, we will likely have to update the position ourselves to ensure the sticky room can be placed appropriately in the list.
Fixes https://github.com/vector-im/riot-web/issues/14798 (part 2)
This is in two parts itself: The `RoomSublist` needs to break its references to the `RoomListStore`, so it now clones the room arrays. The `Algorithm` is the other part, which is slightly more complicated.
It turns out that we weren't handling splicing as a change in the `ImportanceAlgorithm`, therefore the `Algorithm` wasn't really feeling like it needed to change anything. Further, the `Algorithm` was using the wrong reference to where it should be dumping rooms (`this.cachedRooms` is a getter which returns a different object depending on conditions), so having fixed that we need to ensure that the filtered and sticky maps are also updated when we remove a room. Because we send the new tag through a Timeline update, we'll end up updating the tag later on and don't need to update the filter and sticky collections.
The EchoTransaction was wrongly assuming that it knew better than the caller for when the success condition was met, so the echo marking has been left an exercise for the caller. In this case, we mark when we finally receive the sync with the updated rules.
We also have to cancel previous transactions otherwise if the user mashes buttons we could forever show the toast, and that would be bad.
The structure here might need some documentation and work, but overall the idea is that all calls pass through a CachedEcho instance, which are self-updating.
This reduces the update cost of rooms changing, and fixes a bug where when a sublist became filtered it would change the notification count of the sublist.
This does change the expected usage of the state store to ensuring that only one place updates the rooms on the list states, which is currently the room list store. Ideally the state store could listen to the room list store to update itself, however due to a complicated require() loop it is not possible.
In 9969b01c5f we stopped updating the sublist whenever we felt like it, which indirectly froze message previews for room tiles (badges, unread state, etc were unaffected because that is managed by a different store). To fix this, we simply have to listen for changes and perform an update.
We were taking 0.2ms to handle the registration of a timer per event during startup, even before the app is visible to the user. These timers would be short-circuited too, leading to a bunch of wasted time.
0.2ms isn't a lot of time, but multiplied by thousands of events at startup it's pretty significant.
On my account this reduces the full page spinner time from ~50 seconds to just over 20 seconds.
This means we're abusing the AsyncStoreWithClient to get access to a lifecycle, but overall that seems like a minor crime compared to the time spend abusing the store's state as a map.
With thousands of rooms shown, we can save on average 743ms per preview. The new preview time is 0.12ms on average.
Fixes https://github.com/vector-im/riot-web/issues/14694
Instead of spending 10-1000ms in a function iterating over a whole lot of room events, we can use our cached state from the Notification State Store.
This commit sets up a structure that could be applied to communities in the TagPanel too, as that could probably use a similar optimization.
This reduces the updateStatusIndicator() time to just 4ms on average.
Fixes https://github.com/vector-im/riot-web/issues/14475
Background: Sticky rooms are actually a pair of lies to the underlying algorithm as a combination of REMOVE_ROOM/NEW_ROOM calls so they don't get considered as needing to be sorted. When a room is added under the importance algorithm, it is expected that the category it is being added to will be re-sorted to account for the change, however we weren't doing that since we optimized the NewRoom path to be a splice operation.
Fixes https://github.com/vector-im/riot-web/issues/14091
Design needs work, however this is behind labs anyways. This re-implements the behaviour of the old room list.
The implementation ended up being a lot easier due to early confusion with what the TagOrderStore and TagPanel take care of. Turns out they don't deal with tags, but groups. As such, we don't need to do anything with filtering (though we keep some sanity checks in place for safety), and just have to wire up the CustomRoomTagPanel and CustomRoomTagStore.
Michael Telatynski