This fix isn't perfect. Currently the scroll view is
slightly smaller than the list of rooms. I think it has something
to do with the how the heigh is calculate in js, considering it has
some assumptions about the height of each bar and the padding. However
room items are the only things which change with respect to the root
value. Therefore the item list is actually taller than the computed
pixel value of the list converted to rems.
I'll look into it.
DevieListener didn't wait for the user's device list to be downloaded
so it would think the user didn't have cross-signing set up.
Also clear the rest of the state on stop().
Fixes https://github.com/vector-im/riot-web/issues/13372
If we already have an account password to use during secret storage setup, then
it's highly likely that the homeserver accepts passwords for device signing key
upload as well. This change then assumes password auth will work without
checking to avoid a request when the server is under high load.
Fixes https://github.com/vector-im/riot-web/issues/13286
Just a minor thing that is bothersome. Renaming classes and functions is a bit more of an impact than is worth right now, so have settled for littering TODO comments all over the place.
Fixes https://github.com/vector-im/riot-web/issues/13131
Widgets can request an OpenID token to authenticate the user when the widget is missing authentication information. A common case for this is the Dimension sticker picker: sometimes the Riot is running in doesn't have the configuration to match the Dimension instance, so Riot rightly refuses to send an auth token to the widget. When this happens, it requests a token through postMessage().
There's a toggle on the permission dialog to remember the setting, which is the widget's security key. As an added measure, the security key generation ensures the widget URL matches as the 'remember this choice' toggle will silently work in the background, and it could be dangerous if the widget's URL changed and Riot secretly allows the widget to identify the user. This check was failing because the WidgetMessaging class was being set up with the rendered URL, which will not match the widget's URL at all. To fix this, we simply use the widget's URL to set up the messaging, which by proxy uses the right URL in calculating the security key.
Turns out that setUserWidget() wasn't updated to take a real WidgetType, but the code in ScalarMessaging thought it did. This leads to integration managers trying to add sticker widgets with an object `type` rather than a string `type`, which doesn't work.
This updates other code paths which call into the various widget classes to use WidgetType more often. The actual code path for fixing widgets is resolved in WidgetUtils for the setUserWidget function body.
