Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call state can't transition to 'connected' if your call membership already exists #29429

Open
robintown opened this issue Mar 5, 2025 · 0 comments · May be fixed by #29492
Open

Call state can't transition to 'connected' if your call membership already exists #29429

robintown opened this issue Mar 5, 2025 · 0 comments · May be fixed by #29492
Assignees
Labels
A-Element-Call Group calls via Element Call O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect

Comments

@robintown
Copy link
Member

Steps to reproduce

  1. Use a homeserver without support for delayed events
  2. Enter an Element Call group call
  3. Kill the browser while you're still connected
  4. Launch Element once again
  5. Try to re-join the call

alternatively:

  1. Use a homeserver with support for delayed events
  2. Enter an Element Call group call
  3. Kill the browser while you're still connected
  4. Launch Element once again and re-join the call, but do this all very quickly (within the delayed event timeout window)

Outcome

What did you expect?

I re-join the call and Element Web shows that the call is 'connected' in the room list

What happened instead?

I re-join the call and Element Web just says 'video' rather than 'connected' in the room list

Operating system

NixOS 24.11

Browser information

Firefox 135.0.1

URL for webapp

develop.element.io

Application version

Element version: e9a3625-js-3e512711d7ac Crypto version: Rust SDK 0.10.0 (3cc301d), Vodozemac 0.9.0

Homeserver

Synapse 1.125.0

Will you send logs?

No

@robintown robintown added A-Element-Call Group calls via Element Call O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect labels Mar 5, 2025
@robintown robintown self-assigned this Mar 5, 2025
robintown added a commit to element-hq/element-call that referenced this issue Mar 5, 2025
Following a75952c, this is one more upgrade to the widget communication that I'd like to make within this release cycle.

The motivating issue is element-hq/element-web#29429. Fundamentally, without a 'join' action, the only info Element Web can use to determine whether it's joined the call is whether a MatrixRTC membership exists. But membership state events can inaccurately represent the client's actual state (whether because delayed events aren't supported, or because the delayed event hasn't timed out yet), so I suggest we send a 'join' action here just as we do in the Element Web Jitsi wrapper (https://github.com/element-hq/element-web/blob/e9a3625bd6e9a64f216e3caeabca66f48b649332/src/vector/jitsi/index.ts#L503) to let Element Web tap directly into the widget's local state. (This will need additional Element Web changes, but is certainly backwards compatible.)
robintown added a commit to element-hq/element-call that referenced this issue Mar 5, 2025
Following a75952c, this is one more upgrade to the widget communication that I'd like to make within this release cycle.

The motivating issue is element-hq/element-web#29429. Fundamentally, without a 'join' action, the only info Element Web can use to determine whether it's joined the call is whether a MatrixRTC membership exists. But membership state events can inaccurately represent the client's actual state (whether because delayed events aren't supported, or because the delayed event hasn't timed out yet), so I suggest we send a 'join' action here just as we do in the Element Web Jitsi wrapper (https://github.com/element-hq/element-web/blob/e9a3625bd6e9a64f216e3caeabca66f48b649332/src/vector/jitsi/index.ts#L503) to let Element Web tap directly into the widget's local state. (This will need additional Element Web changes, but is certainly backwards compatible.)
fkwp pushed a commit to element-hq/element-call that referenced this issue Mar 10, 2025
Following a75952c, this is one more upgrade to the widget communication that I'd like to make within this release cycle.

The motivating issue is element-hq/element-web#29429. Fundamentally, without a 'join' action, the only info Element Web can use to determine whether it's joined the call is whether a MatrixRTC membership exists. But membership state events can inaccurately represent the client's actual state (whether because delayed events aren't supported, or because the delayed event hasn't timed out yet), so I suggest we send a 'join' action here just as we do in the Element Web Jitsi wrapper (https://github.com/element-hq/element-web/blob/e9a3625bd6e9a64f216e3caeabca66f48b649332/src/vector/jitsi/index.ts#L503) to let Element Web tap directly into the widget's local state. (This will need additional Element Web changes, but is certainly backwards compatible.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Element-Call Group calls via Element Call O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant