matrix-widget-api doesn't receive room events in end-to-end encrypted rooms

Description

I made an Element widget that uses the matrix-widget-api to communicate with other users who also have this widget (by sending and receiving events). This works just fine when using state events or if end-to-end encryption is off for the room. However, room events are not received at all if the room is encrypted; the only indication that something was received is an unread message indicator in Element that appears next to the room name (see the attached screenshot). This indicator doesn't appear when events are correctly received (which is the case for room events in unencrypted rooms and state events).

Steps to reproduce

• Create an encrypted room
• Open a new tab and open the same room again
• Add a widget that uses .sendRoomEvent() and .on() to subscribe to/receive events
• Pin the widget in both tabs and grant the capabilities when requested
• Have the widget send an event and check if it's been received in the other browser tab

I expected that the event would have been received, just like in unencrypted rooms. After all, widgets are not responsible for encryption - Element is. However, no event was received.

Version information

• Platform: web
• Browser: Chrome Version 91.0.4472.77 (Official Build) (arm64)
• OS: macOS 11.4 (20F71)
• URL: develop.element.io

@turt2live The issue is not resolved. In encrypted rooms messages are received with a considerable delay, in random order and only the first 25 that were sent. Also, the unread message indicator still appears.

[turt2live]

The postMessage API by nature is not very fast, but what sort of delay are you seeing?

I'll check the order of things.

The limit is unfortunately a different issue that will have to be looked at, largely from the spec perspective.

The read marker is not intended to be affected by this functionality, and would be a separate issue.

The postMessage API by nature is not very fast, but what sort of delay are you seeing?

I'll check the order of things.

The limit is unfortunately a different issue that will have to be looked at, largely from the spec perspective.

The read marker is not intended to be affected by this functionality, and would be a separate issue.

I'm opening a separate issue, but to sum it up:

1. There's a delay of several seconds before anything is shown at all and between each message there's a noticeable delay that's not present in unencrypted rooms.
2. In unencrypted rooms you receive the last 25 messages when reading, but in encrypted rooms you receive the first 25 that were sent. The behaviour is completely different.
3. There's no unread indicator in unencrypted rooms, only in encrypted ones.
4. Messages arrive out of order (unlike in unencrypted rooms), but I believe that can be solved by sorting them by timestamp.