-
Notifications
You must be signed in to change notification settings - Fork 105
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
Show error screens in embedded widget mode #2955
Comments
Is there a block diagram of the lifecycle of a widget? |
#3011 changes Element Call so that it sends a 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
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 |
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. |
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).
@robintown please update the roll-out plan including the 0.7.2 release unblocking the messenger PRs |
@fkwp done |
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:
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
The text was updated successfully, but these errors were encountered: