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
This reverts a fix to EditableText introduced in
https://github.com/matrix-org/matrix-react-sdk/pull/1445
which introduced a bug that causes room name and topic to
reset when UserSettings is rerendered because
`initialValue != this.value`
This also fixes the same bug originally fixed by #1445:
>fix entering the same thing twice (which had the bug of not
>emptying the "new" field)
which, in other words meant that clicking "+" when adding a room
alias would not reset the contents of the bottom-most alias in the
list.
The fix is to increment the `key` of the element, causing a new
instance to be mounted instead of passing new props to the existing
one.
Widgets would sometimes briefly re-appear after having been deleted.
This was because of the following race:
* User presses delete, send POST req, we set `deleting`. Widget hides.
* POST request completes, we unset `deleting` so widget unhides.
* State event comes down sync so widget hides again.
This fixes this by introducing `waitForRoomWidget` and using it to
wait until the state event comes down the sync until clearing the
`deleting` flag.
Since we now have `waitForRoomWidget`, this also uses it when adding
a widget so the 'widget saved' appears at the same time the widget
does.
Alternative integration managers may wish to also wrap widgets to supply a better user experience. With the previous code, it was not possible to use the integrations_widgets_urls configuration option (described in AppTile). AppPermission should use the same logic to determine if a widget is being wrapped, so it can display a helpful URL for the user (instead of the wrapper URL).
Signed-off-by: Travis Ralston <travpc@gmail.com>
