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.
