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.
* ScalarMessaging onMessage was getting the current room ID by listening
for view_and remembering the room id or alias, and so having to look up
the alias if it was alias. We have RoomViewStore for this.
* Move waitForUserWidget into WidgetUtils
* s/require/import/
ensures that https://scalar.ve can't access the API.
many thanks to @rugk for pointing out the potential vuln.
cc @rxl881 in case this bug has been transplanted elsewhere.
* Implement new widget API
This allows clients to see who provisioned which widgets.
* Update to make state_key the wid
* Update to latest API
* Only show widgets which have required fields
* Don't constantly show apps dialog
* Fix example to include data key
The postMessage API assumed that event origins contained paths of their window origins, but they do not (https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage). This changes the origin check such that the integrations UI URL must start with the event origin.
This takes the form:
The bridge will not create an admin room if there is plumbing state in the room of the form:
```JS
m.room.plumbing: {
content: {
status: "enabled"
},
...
}
```
