I've seen Chromium constantly refresh the title in the developer tools.
To be honest, I'm not sure if this means Chromium wastes CPU
time changing a title, but this may introduce better performance.
Signed-off-by: Resynth <resynth1943@tutanota.com>
and remove the old conference call stuff while we're at it: enough
time should have passed since those mistakes that we can move on.
The old conference call rooms will still appear for anyone whose
account dates back to that time, but they've presumably been appearing
in any other matrix client they used too.
Prototype behaviour:
* If you can't create a room in the community, say so.
* The UX for this could probably be improved, but for now the intention is to not break muscle memory by hiding the create room option.
* If you can't change settings in the community, or can't invite people, don't show those respective options.
* Breaking muscle memory here is moderately okay.
With this change, Element now creates cross-signing keys during auth flows for
password login. For other auth flows like token / SSO, it will not happen until
a cross-signing / secret storage dialog flow as before.
This is a step towards https://github.com/vector-im/element-web/issues/13430
Since we've stored the invite, we can send the user to it once they reload the page or revisit Element. We currently only support one invite at a time, but this should be fine for most cases.
We only do this restoration if the next screen isn't set to avoid breaking the user out of an expected flow.
As an added touch, this also ensures that the email address is pre-filled on the registration page if needed, just in case the user refreshes before getting to the submit button.
If the Secure Backup required mode is set the client `.well-known` file, then
this will ensure that everyone already inside the app is required to complete
setup matching that policy.
Fixes https://github.com/vector-im/element-web/issues/14954
Fixes https://github.com/vector-im/riot-web/issues/14694
Instead of spending 10-1000ms in a function iterating over a whole lot of room events, we can use our cached state from the Notification State Store.
This commit sets up a structure that could be applied to communities in the TagPanel too, as that could probably use a similar optimization.
This reduces the updateStatusIndicator() time to just 4ms on average.
Travis Ralston