See diff for details. Note that this introduces an "Uploading" state which is not currently used.
At the moment, if a user hits the maximum time then their recording will be broken. This is expected to be fixed in a future PR.
Fixes https://github.com/vector-im/element-web/issues/16799
This change replaces the "relative priority" system for filters with a kind model. The kind is used to differentiate and optimize when/where a filter condition is applied, resulting in a more stable ordering of the room list. The included documentation describes what this means in detail.
This also introduces a way to inhibit updates being emitted from the Algorithm class given what we're doing to the poor thing will cause it to do a bunch of recalculation. Inhibiting the update and implicitly applying it (as part of our updateFn.mark()/trigger steps) results in much better performance.
This has been tested on my own account with both communities and spaces of varying complexity: it feels faster, though the measurements appear to be within an error tolerance of each other (read: there's no performance impact of this).
This reworks error handling of "use security key" so we stop the overall
operation when cancelling access (instead of just the immediate prompt). In
addition, flowing the error to outer catch block also handles resetting state to
re-display the initial verification choices.
Fixes https://github.com/vector-im/element-web/issues/15584
Fixes https://github.com/vector-im/element-web/issues/15559
This isn't exactly perfect as an implementation: if the user refreshes immediately after forgetting then there is a good chance the room re-appears because of the sync accumulator. At the very least this change makes it so in *most* cases the room goes away, which is probably good enough until https://github.com/vector-im/element-web/issues/14038 can be implemented properly.
If you opened element and entered a jitsi conference straight away
in the room you landed in, your jitsi display name would be your
matrix username rather than your display name. This was because
OwnProfileStore was still busy fetching your profile from the server
while the room, and therefore jitsi widget, was rendered.
Blocking these widgets loading on this profile fetch completing isn't
really an option, so store the profile data in localstorage and seed
OwnProfileStore with the values from there.
Bonus: the name in the top left will now be your display name as
soon as the app is loaded, rather than being your username for the
first several seconds after you load the app.
Fixes https://github.com/vector-im/element-web/issues/16577
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
Michael Telatynski