Replaces hard-coded pixel values with relative rem units across UI components to improve typography responsiveness and maintainability.
Co-authored-by: Hristo Terezov <hristo@jitsi.org>
* ref: Don't use global context for local state.
* ref: Don't use global context to store the pin.
* feat: Add a test for setting passcode via settings provisioning.
* Use local state.
* Remove "data" from context.
* ref: Rename a function.
* test: Fail quick when join muc fails, assert specific errors (e.g. "token expired").
* test: Add tests for joining a JaaS MUC with different token options.
* ref: Refactor token generation and usage
* ref: Reduce usage of global context
* test: Add a maxOccupants jaas test.
Before the chat message context menu was appearing on the left if the private chat message was disabled. The fix makes the context menu appear on the left only for messages from the local partcipant which are the only messages rendered to the right (therefore the context menu have to appear on the left side). For all other messages the context menu should appear on the right side because the message is positioned on the left side.
The participant pane lost its scrolling capability when commit 2305ae85a removed the overflowY: 'auto' property from the container styles. This prevented users from scrolling through long lists of participants, breakout rooms, or visitors when the content exceeded the available height.
Additionally, context menus were being clipped on the left side due to the overflow constraints. This became apparent after the av-moderation feature added longer menu items like "Stop screen-sharing for everyone else".
Fix:
- Restore overflowY: 'auto' to enable vertical scrolling
- Add maxWidth constraint (285px) to context menus to prevent horizontal clipping
- Allow menu text to wrap to multiple lines instead of being cut off
- Add TODO comment for future portal-based implementation
This temporary solution provides both functional scrolling and fully readable context menus until a proper architectural change can be implemented to portal context menus outside the scrollable container.
- Move namespace declaration to correct location in build.gradle
- Remove deprecated package attribute from AndroidManifest.xml
- Update README with gradle plugin version requirement
- Fix Android namespace configuration for React Native SDK
These changes resolve installation and build errors when integrating
the Jitsi Meet React Native SDK into new projects.
Fixes: SDK installation failures on Android with newer Gradle versions
When a moderator joins or someone is granted moderation we update the whitelist for any media type for which moderation is enabled. The updated whitelist is sent to all the moderators including the newly joined or granted one.
Visitors with empty or undefined names now show the configured
defaultRemoteDisplayName or 'Fellow Jitster' as fallback, matching
the behavior of regular remote participants.
We were comparing if the number of waiting participants have changed with the wrong property from the state - the number of visitors. The result was that we won't update the state when the new waiting value matches the number of visitors already in the state. Most of the times this will be 0 and we would never go to 0.
Remove filtering on the receive side, because:
1. It's not applied to visitors, and should be for the "all" case
2. We don't want to strip stats-id from stanzas sent to jicofo
* JIT-14750 Do not show names to visitors
* apply review
* change name and email too
* fix: Fix filtering initial presence to vnodes.
* Also strip stats-id and identity.user.name.
* Move filtering logic to a util, filter all identity in main room
---------
Co-authored-by: Boris Grozev <boris@jitsi.org>
Adds .web suffixes to all web specific files to prevent beeing included in the native build. Before this it seems those files were included in the build but by some chance nothing was failing.
When we open a custom scheme URL before the window load event has been fired it seems that GUM prompt is not displayed after this due to Chrome bug. See more details here https://issues.chromium.org/issues/41398687.
The result in Jitsi Meet is the following:
If the user is joining a call for first time and haven't granted A/V permissions and lands on the deeplinking page we try to open the desktop app via redirect to a custom scheme URL. If the user chooses cancel and "Launch in web" we go to the prejoin screen and proceed with the initial GUM. At this point any GUM call won't display the permission prompt due to the browser bug and will go on forever making it impossible for the user to unmute camera or microphone.
