Let the notifications go into browser/OS notification trays so users can click on them from there if they miss the initial notification. Modern Chrome uses OS notifications so the user is in control of the the notification with the OS. This also aligns with the Electron platform version.
Signed-off-by: Matthew Noorenberghe <github@matthew.noorenberghe.com>
Effectively fixes https://github.com/vector-im/riot-web/issues/11074
Effectively fixes https://github.com/vector-im/riot-web/issues/7112
Fixes https://github.com/vector-im/riot-web/issues/6930
Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933)
Fixes https://github.com/vector-im/riot-web/issues/5048
Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json.
This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event.
Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires.
A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
Before this change, you had to scroll down to see the noscript element.
This change places the noscript element on top of the page making sure
that a user will see this message when site is loaded without JavaScript.
Signed-off-by: Karol Kosek <krkk@krkk.ct8.pl>
Imports are optimized to be concurrent/async by webpack, which means that when the old index.js referenced the Lifecycle from the react-sdk it caused the app to explode. This is because in another branch the Lifecycle references a class member of a skinnable component, leading to the skinner complaining that the skin hasn't been loaded.
To work around this, we've shoved all the app stuff to a new app.js file, leaving just the skinning and some early bootstrap work in the index.js
We have to convert *something* to TypeScript so it doesn't complain that there's nothing to compile, so this converts the easiest utility library.
Many of the scripts are copied from the react-sdk.
This will have done its job now, everyone's had long enough to
install a newer version of Riot and migrate to the new origin.
Laves the code on the backend that handles it for the time being,
as per comment.
Following on from https://github.com/matrix-org/matrix-react-sdk/pull/3637
this removes the code dealing with themes in vector/index.js and uses the
code from react-sdk. The two did almost exactly the same thing but in
subtley different ways.
This code can be incredibly subtle though, so doing this a separate
PR.
A thesis presented in two parts. This part has the absolute minimum
logic changes to the themeing code in vector/index.js because I know
how subtle and fragile this code is. However, it also looks like it's
completely duplicated from react-sdk, so in the next part I'm going
to remove that logic and make it use the logic in react-sdk, then we
can see what breaks.
Requires https://github.com/matrix-org/matrix-react-sdk/pull/3637
It's still not 100% clear whether storage is always persistent on
Electron, but we seem to be getting reports of it being deleted in
the wild on Electron, so let's try calling the API to request
persistent storage. It won't pop up a dialog on Electron. In the
worst case it will give us some logging so we know what the API calls
return.
We could do this on non-desktop too but it's a bit of a mess because
Firefox prompts the user but Chrome makes a decision itself based on
how much the user visits the site.
