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

Show error screens in embedded widget mode #2955

Open
1 task
robintown opened this issue Jan 16, 2025 · 5 comments · May be fixed by element-hq/element-web#29254
Open
1 task

Show error screens in embedded widget mode #2955

robintown opened this issue Jan 16, 2025 · 5 comments · May be fixed by element-hq/element-web#29254
Assignees
Labels
T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements X-Release-Blocker

Comments

@robintown
Copy link
Member

robintown commented Jan 16, 2025

Implementation

This enhancement requires implementation in each of our clients.

These PRs are blocked until we are certain that we'll have a stable release up on call.element.io which sends 'close' actions within the current release cycles of EW and EX. To unblock and roll them out sooner, the plan is to backport the sending of the 'close' action to a v0.7 release.

Your use case

element-hq/element-x-ios#3813

What would you like to do?

Make sure that the error screens we're adding to the application can be shown in embedded mode as well, without the client immediately hiding the widget.

Why would you like to do it?

Because we're putting effort into creating helpful error screens, and it would be a shame for the experience in embedded mode to still just be:

  1. An error occurs
  2. The widget closes immediately
  3. ??? Confusion
  • Reconsider actionable error screen actions in widget mode. (if we are not connected to the RTC session EW should display a X icon)

How would you like to achieve it?

When an error occurs, tell the widget to no longer be "always on screen", so that it can be closed, but at the same time make sure Element Web etc. won't just react to the disconnection by closing it immediately.

Have you considered any alternatives?

No response

Additional context

No response

@robintown robintown added the T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements label Jan 16, 2025
@hughns hughns changed the title Show error screens in embedded mode Show error screens in embedded widget mode Feb 6, 2025
@robintown robintown self-assigned this Feb 10, 2025
@fkwp
Copy link
Contributor

fkwp commented Feb 21, 2025

Is there a block diagram of the lifecycle of a widget?

@hughns
Copy link
Member

hughns commented Feb 24, 2025

#3011 changes Element Call so that it sends a hangup and close action to the widget host.

Old messenger clients will continue to behave the same with new EC (because EC is sending both actions).

We then change the messenger widget hosts so that they ignore the hangup and only close the widget on a close:

When these PRs land older EC versions (pre #3011) will then have a broken UX when the user hangs up. They get left on a blank EC screen.

Because of this broken UX we don't want to merge the messenger changes until we have a newer version of EC running on call.element.io.

@hughns
Copy link
Member

hughns commented Mar 3, 2025

During discussion today the idea of making a change to EC 0.7.x so that it isn't broken with the new EX/EW PRs came up. This would mean that we can decouple the rollout of this somewhat. @robintown will look at this.

robintown added a commit that referenced this issue Mar 4, 2025
This is a watered-down version of the changes in 832a5aa which should be suitable as a patch to the v0.7 release series. It makes Element Call widgets send a 'close' action in addition to the original 'hangup' action, and nothing more.

The point is that we can then deploy this change to call.element.io with little effort so that clients are more immediately free to expect a 'close' action from Element Call (and thus we unblock #2955 and element-hq/element-web#29196).
@fkwp
Copy link
Contributor

fkwp commented Mar 5, 2025

@robintown please update the roll-out plan including the 0.7.2 release unblocking the messenger PRs

@robintown
Copy link
Member Author

@fkwp done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements X-Release-Blocker
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants