- Don't initialize handler's is their API key is not set
- Don't swallow exceptions when creating handlers
- Don't remove all handlers if an external one fails
- Dispose the analytics subsystem if no handlers are registered
Get the existing HTMLVideoElement for large video instead of creating a new video element for capturing the screenshot.
This should prevent the video player from getting displayed on mobile Safari.
* feat: Make possible to reload config for filter rayo iq.
* feat: Throttle out call attempts to the max number per minute
* squash: Updates comment about config
app.bundle.js before: 3851549 after: 4506493.
The culprit for the bloat was Olm. It feature-detects the environment in order
to pick a suitable random byte generator, and alas Webpack includes the None
crypto pollyfill. This is due to the existence of the "node" block in our
Webpack configuration file.
The solution is to provide empty modules to make bundling work, as we did
already for the fs module, since we know they are not used at runtime.
The stream is attached before the video type change event is fired, so comparing
them is too late. Unconditionally update the screen-sharing indicator, and
perform the check for a change right there, to avoid re-renders.
Ever since https://github.com/facebook/react-native/pull/23674 landed it has
been possible to run timers in the background, assuming your app is allowed to
run in the background already, as is our case. So, stop using the library on
iOS, which will avoid creatring needless backgound tasks.
The RN Permissions module calls this in a non-UI thread. What we observe is a
crash in ViewGroup.dispatchCancelPendingInputEvents, which is called on the
calling (ie, non-UI) thread. This doesn't look very safe, so try to avoid a
crash by pretending the permission was denied.
When returning the error and showing to user not allowed screen we were not completely halting the prejoin operation when token verification fails on room join and the token is valid in general.
Adapt to E2EE changes in lib-jitsi-meet. Notably:
---
e2ee: introduce per-participant randomly generated keys
This the second stage in our E2EE journey.
Instead of using a single pre-shared passphrase for deriving the key used for
E2EE, we now establish a secure E2EE communication channel amongst peers.
This channel is implemented using libolm, using XMPP groupchat or JVB channels
as the transport.
Once the secure E2EE channel has been established each participant will generate
a random 32 byte key and exchange it over this channel.
Keys are rotated (well, just re-created at the moment) when a participant joins
or leaves.
---
Saúl Ibarra Corretgé
Jaya Allamsetty
Tudor-Ovidiu Avram
paweldomas
Дамян Минков
Jaya Allamsetty
Vlad Piersec
Josh Brown
Julian Vos
Manuel Garcia
yjhgull
Joris Bodin
Aaron van Meerten