Conversation
dc635a0 to
818269a
Compare
818269a to
2d386ca
Compare
2d386ca to
6c7da2a
Compare
826365b to
a31991c
Compare
This is an implementation of an update to MSC2762, which provides a new action for informing widgets of changes to room state.
|
toger5
left a comment
There was a problem hiding this comment.
This is quiet a bit of work with the queuing that needs to happen.
Looking through the PR it definitely makes a lot of sense that its needed.
The PR looks good!
| // If new events are allowed and the currently viewed room isn't covered | ||
| // by a timeline capability, then this is the widget's opportunity to | ||
| // learn the state of the viewed room | ||
| if (allowedEvents.length > 0 && this.viewedRoomId !== null && !this.canUseRoomTimeline(this.viewedRoomId)) { | ||
| this.pushRoomState(this.viewedRoomId); | ||
| } |
There was a problem hiding this comment.
I cannot follow this based on the comment. Shouldnt the widget never see any room if it does not have the timeline capability. Not event the viewed one? Or was that one of the widget api confusions. In that case it would be super helpful to provide that background here.
There was a problem hiding this comment.
Tried another wording with the comment; the widget can always interact with the currently viewed room as reflected by the comment on setViewedRoomId.
| `org.matrix.msc2762.timeline:${roomId}`, | ||
| `org.matrix.msc2762.receive.state_event:${type}`, | ||
| ]); | ||
| await loadIframe(['org.matrix.msc2762.receive.state_event:net.example.test#B']); |
There was a problem hiding this comment.
why do we remove the timeline capability here?
There was a problem hiding this comment.
We don't need it as long as the room is being viewed.



This is an implementation of an update to MSC2762. See the description there for an explainer.