Jitsi

Recent Commits

• bgrozev(03 Sept 26)

  Default advancedAudioSettings to enabled (#17781) * feat: default advancedAudioSettings to enabled isAdvancedAudioSettingsEnabled now returns true unless audioQuality.enableAdvancedAudioSettings is explicitly set to false, instead of requiring it to be explicitly true. * doc: document enableAdvancedAudioSettings in config.js

• bgrozev(03 Sept 26)

  fix(chat): prefer the tracked participant's display name over the message's visitor flag (#17777) A resolvable, tracked participant now always wins when computing the displayed sender name, instead of the per-message isFromVisitor flag being checked first. A genuine visitor is never tracked as a participant, so this doesn't change behavior for real visitor messages.

• dependabot[bot](03 Sept 26)

  chore(deps): bump @xmldom/xmldom from 0.8.13 to 0.8.15 Bumps [@xmldom/xmldom](https://github.com/xmldom/xmldom) from 0.8.13 to 0.8.15. - [Release notes](https://github.com/xmldom/xmldom/releases) - [Changelog](https://github.com/xmldom/xmldom/blob/master/CHANGELOG.md) - [Commits](https://github.com/xmldom/xmldom/compare/0.8.13...0.8.15) --- updated-dependencies: - dependency-name: "@xmldom/xmldom" dependency-version: 0.8.15 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>

• dependabot[bot](02 Sept 26)

  chore(deps-dev): bump fast-uri from 3.1.5 to 3.1.7 Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.5 to 3.1.7. - [Release notes](https://github.com/fastify/fast-uri/releases) - [Commits](https://github.com/fastify/fast-uri/compare/v3.1.5...v3.1.7) --- updated-dependencies: - dependency-name: fast-uri dependency-version: 3.1.7 dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>

• Jaya Allamsetty(02 Sept 26)

  fix(virtual-background): vendor the TF.js selfie segmentation model Load the MediaPipe selfie segmentation TF.js graph model from the deployment's libs/ directory instead of tfhub.dev, so V2 works in offline and firewalled environments. Fixes #17768

• Дамян Минков(02 Sept 26)

  fix(prosody): scope refreshed token claims to the joined conference (#17769) * fix(prosody): scope refreshed token claims to the joined conference A connection resuming a hibernated session (XEP-0198) may present a different token than the one the session joined with, and mod_auth_token refreshes the claims of the live session from it -- that is how a client rotates an expiring token across a reconnect. The room claim is scoped to a conference on muc-room-pre-create and muc-occupant-pre-join only, and neither runs again for a session that is past its join, so the refreshed claims were adopted whichever room the token was issued for. mod_auth_token now fires 'jitsi-verify-session-rooms' before keeping the refreshed claims. mod_token_verification, which owns room verification, answers it by running verify_room against the rooms the session already occupies -- the main room it came from when it sits in a breakout room -- and the claims verified on join are kept when the new ones do not cover them. Deployments without mod_token_verification have nothing answering the event and behave as before, matching the fact that their joins are not room-checked either. Adds integration tests for the resumption paths, a session-live endpoint on the test observer (the session-info snapshot is taken at resource-bind, which a resume does not perform), and leaveRoom / dropConnection URL parameters in the test client. * refactor(prosody): check the recorded room instead of every live room mod_token_verification records the conference a session is verified for when it lets the join through (jitsi_meet_verified_room) and answers 'jitsi-verify-session-rooms' with a single lookup of that room, rather than iterating over every live room of the component looking for the session. Being an occupant is no longer required, so the jitsi_breakout_main_jid special case is gone: a session that moved into a breakout room has left the main room it joined, and that main room is still the conference its claims have to cover. A room that no longer exists is skipped. * test(prosody): cover adopting a rotated token in a breakout room The existing breakout test only checks that a token for another room is refused. It passes either way when the room the claims are verified against is wrong, so a regression pointing the check at the breakout room instead of the main room the session joined would go unnoticed: that fails closed and the assertion still holds. Adds the positive counterpart, which asserts a token that does cover the main room is adopted while the session sits in a breakout room, and extracts the shared breakout setup the two tests now use. --------- Co-authored-by: Boris Grozev <[email protected]>

• damencho(02 Sept 26)

  test(prosody): accept either surface of a mod_muc_auth_ban rejection mod_muc_auth_ban's HTTP callback calls session:close(), and where that lands depends on when the access manager answers. It runs on the same prosody process, so it usually answers within the same event loop tick as the SASL auth and the connection is refused outright, which is what the test asserted. Under load it can answer a tick later, in which case the session is established and then closed, and the test failed on a ban that had worked. Assert that the session was banned without pinning which of the two it was.

• Jaya Allamsetty(02 Sept 26)

  fix(conference): Remove the window hook for the legacy Electron picker. lib-jitsi-meet was the only caller of window.JitsiMeetScreenObtainer and stopped calling it when the legacy Electron path was removed there, so the hook can no longer fire. The picker itself stays. The Electron SDK opens it over the iframe API during getDisplayMedia, so react/features/desktop-picker and the open-desktop-picker command are still in use.

• Дамян Минков(02 Sept 26)

  feat(chat): apply message moderation, editing and retraction on the server (#17763) * feat(prosody): handle chat message moderation, editing and retraction Add mod_muc_message_moderation, making the room the authority for the three chat operations that were until now synchronised between clients and patched up by every participant replaying state to a joiner: - moderation (XEP-0425), honoured for occupants holding the moderator role, replacing the room history entry with a tombstone - correction (XEP-0308) and the json EDIT_CHAT_MESSAGE the client broadcasts today, honoured for the author, rewriting the history entry body in place - retraction (XEP-0424), honoured for the author, removing the entry outright A request that does not pass its check is dropped and reaches nobody. Late joiners then receive history that is already correct, so nothing needs to be sent to them once they are in. The json edits are picked up from jitsi-endpoint-message-received, where such payloads are already decoded, rather than decoding the stanza again. Rooms advertise muc#roominfo_messageModerationEnabled so a client can hide the actions where the module is not loaded. Visitor nodes are covered as well. A moderation is sent by the room, so the hook in mod_visitors that forwards occupant messages never sees it: the module fires jitsi-message-moderated and mod_visitors fans that out to the connected vnodes. Load the module on the visitor prosody too, where it does no checking of its own, since every request is checked on the main prosody, which is where the room the occupants act in lives. There it brings the local history in line and announces the moderation to its own occupants. It builds that stanza rather than relaying what arrived, because the room is not an occupant of the visitor node's room and the from would then depend on how the hop rewrites it, and it routes only to occupants on the local domain, as the main prosody has already told its own participants. * ref(chat): take message moderation state from the server Drop moderatedBy. The room decides who may moderate and the value was never rendered, so moderateMessage and MESSAGE_MODERATED now carry only the message id and the reason. The endpoint message path that brings late joiners up to date is honoured only for senders holding the moderator role, and its reason is capped the same way an edit is. Gate the edit and both delete actions on messageModerationSupported so they are hidden where the server does not apply them, and restrict the moderator delete to other people's messages, so exactly one delete is offered at a time and it is the author's own retraction on their own message. Hide the retraction of a message that has already been moderated. Add the missing chat.delete string, pass the message to sendMessageModeration instead of a cast carrying only an id, and drop the messageId prop that duplicated message.messageId. * fix(prosody): keep the visitor node history for the messages it routes Prosody writes room history from broadcast_message, and routing straight to the occupants bypasses it, so a visitor node's history stayed exactly as the main prosody left it when the node connected. A visitor joining an already connected node saw nothing that had been said since, from either the main participants or the other visitors, because that is the history their client is served. Append the stanza to the local history after it has been routed, in the same shape prosody's own writer uses and honouring the same storage hints. Append it directly rather than firing 'muc-add-history': the handlers on that event are meant for the room the participants act in, and some of them expect the sender to be a local occupant, which a main participant never is here. * fix(prosody): apply edits and retractions to the visitor node history Two things kept a visitor node's history from reflecting an edit or a retraction. The payload type was wrong. EDIT_CHAT_MESSAGE is 'editChat' in react/features/chat/constants.ts, not the name of the constant, so the comparison never matched and no json edit was ever acted on, on the main prosody either. Its history was left holding the original body just the same, so a late joiner there saw the text before the edit. The constant now carries a comment naming its counterpart, and a test reads the value out of that file rather than restating it, since the fixtures agreeing with the module on a value the client never sends is what hid this. The visitor node also only handled moderation. A retraction or an edit arrives as a main participant's stanza, and main participants are occupants of the visitor node's room, so the check for a stanza without an occupant skipped both. Handle them from the same hook, and take the json payload from the stanza there rather than from 'jitsi-endpoint-message-received', which is fired by mod_muc_meeting_id and is not guaranteed on a visitor prosody. What may be applied is decided in one place. Anything that arrived from the main prosody is applied as it stands, since it was checked there. A visitor's own request has not been past the main prosody at the point this node routes it, so the author is checked against the local entry; without that a visitor could put forged text into the history every later visitor is served. Adding the routed message to the local history now goes through prosody's own muc-message-is-historic and muc-add-history events rather than building the entry in fmuc. Building it there duplicated prosody's writer and bypassed the muc-add-history handlers, one of which is this deployment's own: skip_history keeps the stanzas carrying a moderation, a correction or a retraction out of history, and a XEP-0308 correction has a body, so the local gate would have stored it as a message of its own and served a joining visitor two copies. * ref(chat): move message editing to XEP-0308 Editing was the only one of the three chat operations not carried by a stanza the server understands. It travelled as a json payload of type 'editChat', which the receiving client drops when it arrives delayed, so an edit was never part of the history a joining client is served. Every participant had to replay their own edits privately to each new joiner to make up for it, and the prosody module had to decode a jitsi private payload and match a string constant to know that an edit had happened at all. A correction is now an ordinary message carrying the new body, a <replace/> naming the message it corrects and a 'store' hint. The room archives it and replays it in order after the message it corrects, so a client joining later applies it the same way one already in the room does, and the edited marker survives a rejoin. This drops the endpoint message path, the private message path, the replay on join and the constant. In the module it drops the json parsing and the cjson dependency, the handler on jitsi-endpoint-message-received, and the rewriting of the history entry along with keeping the correction out of history. What remains is the check that a correction comes from the author of the message it names, and is refused on a message that has been moderated. * squash: Drop comment and correct check.

• damencho(02 Sept 26)

  chore(deps) lib-jitsi-meet@latest https://github.com/jitsi/lib-jitsi-meet/compare/v2198.0.0+de1cc170...v2199.0.0+65bd4621

• Jaya Allamsetty(01 Sept 26)

  chore(deps) lib-jitsi-meet@latest https://github.com/jitsi/lib-jitsi-meet/compare/v2197.0.0+3ba4df05...v2198.0.0+de1cc170

• damencho(01 Sept 26)

  test(time-timer): stop assuming the deployment enforces no limit Both specs assumed a target where nothing else drives the timer. Alpha now sets timeTimer.suppressForSeconds = 180 and runs mod_time_restricted, which pushes its own limit to every occupant on join, so both assumptions broke: setMeetingTimer "shows the timer pill when a duration is pushed" pushed elapsed=0, inside the 180 s window, so the pill stayed hidden timeTimer "joining the meeting" asserted no timer was running, but the server had already started one The 180 s window was also masking the server-pushed timer, which is why the preceding "does not show the timer until a duration is pushed" passed - for the wrong reason. Pinning the window to 0 fixes the first failure and uncovers that one. So assert on which timer is running rather than whether one is. Both specs now pin suppressForSeconds and key off durationSeconds, using a value no deployment would enforce: the forged/pushed 1800 s is either adopted or it is not, and a server-enforced limit alongside it changes nothing. Works with or without mod_time_restricted.

• Дамян Минков(01 Sept 26)

  fix(time-restricted): Time limited module and updates to use the UI timer (#17494) * fix(time-restricted): Initial module import. * feat(time-restricted): improve room destroy message with duration * feat(time-timer): start countdown from mod_time_restricted server message The mod_time_restricted plugin now broadcasts a 'time_restricted' json-message at the meeting's half-way point (and to occupants joining after it), sent from the room JID so lib-jitsi-meet surfaces it as a NON_PARTICIPANT_MESSAGE_RECEIVED. The time-timer middleware turns that into startTimeTimer so the visible countdown reflects the server's enforced limit, with elapsedSeconds keeping late joiners in sync. The handler only honours messages with no sender resource (id === null, i.e. straight from the room JID), so a participant cannot forge a timer by sending the json-message into the room. * test(time-restricted): add prosody integration tests Covers the half-way time_restricted json-message broadcast (sent from the room JID so it surfaces as NON_PARTICIPANT_MESSAGE_RECEIVED), the late-joiner path, and room destruction with the friendly time-limit reason plus re-creation blocking. The module is loaded on demand in the spec rather than globally so it does not tear down other specs' rooms; conference_max_minutes = 0.125 in the test config keeps the run to ~19s. The destroy-reason format is switched from %d to %g so a fractional limit does not crash the timer (identical output for whole-minute production configs). * test(time-timer): disable the timer by default in tests Adds timeTimer.enabled = false to the default test participant config so the timer cannot interfere with unrelated tests. The setMeetingTimer spec now enables the feature explicitly and relies on the default config for its feature-disabled case. * feat(time-restricted): notify when joining a room past its time limit Once mod_time_restricted destroys a room it refuses to let it be re-created, bouncing the join presence with a 'cancel'/<resource-constraint/>. lib-jitsi-meet now matches that condition in ChatRoom.onPresenceError and raises CONFERENCE_TIME_LIMIT instead of the generic connect error, so tell the user the meeting ran out of time rather than that something went wrong with the connection. Needs the matching lib-jitsi-meet change; until the dependency is bumped JitsiConferenceErrors.CONFERENCE_TIME_LIMIT is undefined and the case simply never matches. * feat(time-timer): push the limit on join, add a client suppression window mod_time_restricted waited until the meeting's half-way point before telling clients about the limit, so the client had no idea a limit existed for the first half of the meeting and the "when to show the countdown" decision lived on the server. Send the timing info to every occupant as they join instead - first joiner and late joiner alike - so the client always holds the full picture. Deciding when the countdown appears now belongs to the client: `timeTimer.suppressForSeconds` keeps the pill off screen until the meeting is that many seconds along. It is off by default (0 - show as soon as a duration is known), and the threshold is measured from the meeting's scheduled start rather than from when this participant joined, so the pill appears at the same moment for everyone and a late joiner past the window sees it right away. Setting it to half the limit reproduces the old server-side behaviour. Visibility now has a single selector, isTimeTimerVisible, used by both the pill and the info bar - the pill supersedes the subject and conference-timer labels, so gating only the pill would have left the bar empty during the suppression window. Suppression is display-only: the timer still runs and the end-of-meeting notification still fires on schedule. * feat(time-restricted): add a wrap-up grace period before destroying a room Reaching the limit tore the room down on the spot, cutting people off mid-sentence. `conference_grace_seconds` grants gratis time past the limit so they can say their goodbyes and leave on their own. Only the teardown moves: clients are still told the meeting's duration is the limit itself, so their countdown ends on time and they spend the grace period in the visible over-schedule state - which is exactly the cue to wrap up. Someone joining during the grace lands directly in that state too, since the module reports elapsed past the duration. Defaults to 0, i.e. the current destroy-at-the-limit behaviour. The integration test config grants 3 s and the spec now asserts the room outlives its limit by it. * test(time-timer): prove a participant cannot forge a time_restricted message The client honours a `time_restricted` json-message only because it arrives from the bare room JID: lib-jitsi-meet derives the endpoint id from the stanza's resource, and the time-timer middleware ignores the message unless that id is null. Nothing covered either half of that. Prosody side (mod_time_restricted_spec): an occupant sends the payload three ways - plain groupchat, groupchat with a forged from="<roomjid>", and a private message to another occupant with the same forged from. Every one is delivered re-stamped with the sender's occupant JID; the claimed identity is discarded rather than the stanza being dropped. Needs the new sendJsonMessageRaw() escape hatch to build stanzas a well-behaved client never would. Client side (timeTimer.spec): a message injected with a sender id is ignored, and the same payload with a null id starts the timer - the positive control that keeps the rejection cases from passing vacuously. * feat(time-restricted): notify on the conference-request time limit too Joining a room past its limit showed "Connection failed. Please try again later!" with a Rejoin button. The presence handling added earlier never runs in practice: jicofo creates the room, so jicofo is what gets refused, and the failure comes back through the conference request as a connection error rather than through our own join presence. lib-jitsi-meet now raises TIME_LIMIT_ERROR for that case, so map it to the same message the presence path uses. No Rejoin action - the meeting is over and retrying would be refused identically.

• damencho(31 Aug 26)

  chore(deps) lib-jitsi-meet@latest https://github.com/jitsi/lib-jitsi-meet/compare/v2196.0.0+fee08f54...v2197.0.0+3ba4df05

• bgrozev(31 Aug 26)

  feat(client-requirements): notify the user when the client needs an update. (#17730) * feat(client-requirements): notify the user when the client needs an update. Handle the new CLIENT_REQUIREMENTS_NOT_MET event: show an error when the server does not allow this client in the conference because it does not advertise a required capability, and a warning when the capability is only expected. The warning can be hidden with the new hideMissingCapabilityWarnings config option. * feat(client-requirements): link only a part of the notification text. Do not render a raw URL. On web the link goes around a "See details here" phrase, and on native the URL becomes a button, because the native notification renders text only.

• bgrozev(31 Aug 26)

  chore(deps) lib-jitsi-meet@latest (#17762) https://github.com/jitsi/lib-jitsi-meet/compare/v2195.0.0+48c54c20...v2196.0.0+fee08f54

• Marco Scammacca(03 Aug 26)

  fix(whiteboard): prevent reopening closed whiteboard on unrelated metadata updates

• Mihaela Dumitru(31 Aug 26)

  feat(recording): redesign the record & transcribe dialog (#17746) * feat(recording): redesign the record & transcribe dialog Per-section start/stop with immediate actions, collapsible options accordions with choice summaries, themed dropdowns for storage service and transcription language, recorder follow-me in the dialog, and start/stop-both footer actions. Applies to web and native via the shared abstract components; e2e page object and specs updated. * test(recording): add config-matrix and mixed-running-state coverage for the record dialog Adds an e2e spec covering the Record & Transcribe dialog against the full enabled/disabled matrix of recordingService, transcription, localRecording and liveStreaming config flags, plus the mixed recording/transcription running-state combinations, and the recordingService.sharingEnabled / localRecording.notifyAllParticipants sub-flags. Extends RecordingTranscriptionDialog and Toolbar pageobjects with the selectors needed to observe these states. * fix(recording): wire up recordAudioAndVideo to focus the transcription section recordAudioAndVideo was documented to collapse the recording section and expand transcription on open, but was never forwarded from RecordingTranscriptionDialog to StartRecordingDialogContent nor read by AbstractStartRecordingDialogContent, so the async-transcription/nudge entry points that rely on it silently did nothing. * fix(recording): drop dead initialRecording/initialTranscription nudge props These props were removed from the dialog during the redesign, so passing them from the recording/transcription nudge notifications silently did nothing. recordAudioAndVideo (now wired up) already covers both nudge cases: false focuses transcription, and the default (true) already focuses recording. * fix(recording): preserve isRecordingRequested when starting transcription alone Starting transcription independently while a Dropbox/local recording was already running overwrote the conference's recording metadata with just {isTranscribingEnabled: true}, dropping isRecordingRequested. The metadata listener reads that as recording having stopped, firing a spurious "recording stopped" notification/sound to every participant while the recording is still running. Spread the existing metadata, same as the sibling stop-recording and stop-transcription branches already do. * fix(recording): fall back to the first option when the selected value disappears If the currently selected service/language stops being an available option while the dialog stays open (e.g. a recording starts and cloud options become unavailable), the dropdown trigger rendered a blank label instead of a usable name. Fall back to the first option's label in that case. * fix(recording): type the native content constructor instead of using any StartRecordingDialogContent's own constructor could use the existing IProps type from its parent class one import away instead of any. mapStateToProps' ownProps stays any: this component is a react-navigation Screen, and its generic route/navigation prop types don't compose with a narrower own-props type without modeling the whole navigation ParamList (documented inline). * perf(recording): stop recomputing recording options and summaries per render _getRecordingServiceOptions() was called up to three times per render (_shouldRenderFooter, the section's own _shouldRenderRecordingSection guard, and the options mapping) — compute it once in _renderRecordingSection() and pass it into _shouldRenderRecordingSection() instead. _getRecordingSummary()/_getTranscriptionSummary() (each doing several t() calls) ran unconditionally even though _renderAccordion only displays the summary while collapsed — skip computing them while expanded. * refactor(recording): hoist the six start/stop-then-dismiss wrappers to the base class Web and native RecordingTranscriptionDialog each independently defined _onStartRecordingPress/_onStopRecordingPress/_onStartTranscriptionPress/ _onStopTranscriptionPress/_onStartBothPress/_onStopBothPress — identical except for the dismiss call (hideDialog() vs goBack()). Move the six wrappers into AbstractStartRecordingDialog and add a _dismiss() hook that each platform overrides once, following the same pattern already used for _toggleScreenshotCapture. * refactor(recording): reuse LanguageListItem for the transcription-language rows The native transcription-language list rendered RecordingOptionRow over the same "translation-languages:"-prefixed data the subtitles feature's LanguageListItem already renders for the same job (checkmark + label + pressable), including its own t() translation. Reuse it instead of re-deriving the label locally. RecordingOptionRow remains for the recording-service rows, which aren't language data. * refactor(follow-me): centralize the recorder/regular Follow Me exclusivity rule The rule that Follow Me and Follow Me Recorder are mutually exclusive was hand-rolled a third time in the new recording dialog (alongside the existing settings/web/ModeratorTab.tsx and settings/native/ ModeratorSection.tsx implementations, each via their own mechanism). Add a setFollowMeRecorderExclusive thunk to the follow-me feature so this call site dispatches the rule instead of re-deriving it locally, and drop the now-unused _followMeEnabled prop that only existed to feed it. * fix(lang): remove recording keys orphaned by the dialog redesign recording.serviceDescription, recording.uploadToCloud and recording.showAdvancedOptions were dropped from lang/main.json by the dialog redesign but never removed from the 59 translated locale files, failing the "Check lang files for translation errors" lint job (superfluous-key). Removed from every locale file that still had them; lang/main.json itself was never affected. * fix(tests): avoid no-loop-func lint error in recordingDialogConfig.spec.ts The matrix describe's it() closures, created inside a nested for loop, referenced localRecordingSupportedByBrowser as a reassigned outer let, tripping @typescript-eslint/no-loop-func. Hold it in a const-bound object instead; only its property changes, and that happens once in 'setup' before any of the loop's tests run. --------- Co-authored-by: damencho <[email protected]>

• Rub3nCT(31 Aug 26)

  fix(lang) update Spanish translation

• bgrozev(27 Aug 26)

  fix(av-moderation): send reject before mute request (#17755) * fix(av-moderation): send reject before mute request Jicofo mutes a participant on the bridge only if the participant is not allowed to unmute when jicofo receives the mute request. Jicofo does not calculate the mute state again when the whitelist changes. The client sent the mute request before it removed the participant from the A/V moderation whitelist. Jicofo received the mute request while the participant was still on the whitelist, thus it only forwarded the mute request to the participant. A participant that does not obey the mute request continued to send audio until the moderator muted it a second time. Send the reject first, then the mute request. The new muteRemoteAndReject action keeps the order in one place, for all mute actions. The mute-everyone dialogs also change the moderation state before they mute the participants, for the same reason. The moderator UI used the mute state that a participant reports in presence to hide the mute action. A participant can report a state that is not correct, which removed the only action that mutes the participant on the bridge. Keep the mute action available while the participant can be removed from the whitelist. The new canRejectParticipant function holds this condition, and the reject actions use it too. * test(av-moderation): open the participants pane only if closed

• bgrozev(27 Aug 26)

  ref(lobby): check that a lobby notification comes from a moderator. (#17760) Prosody sends the notification with the moderator which performed the action as the sender, and only a moderator can enable or disable the lobby, or admit or reject a participant. Show a notification only for an action which the sender is able to perform.

• damencho(27 Aug 26)

  chore(deps) lib-jitsi-meet@latest https://github.com/jitsi/lib-jitsi-meet/compare/v2194.0.0+2d91ec2a...v2195.0.0+48c54c20

• damencho(27 Aug 26)

  fix(tests): Wrong selector.

• damencho(27 Aug 26)

  test(harness) log the browsers in use for every spec The participant console logs, which is where the browser version shows up, are attached to the report only when a test fails, so a passing run leaves no record of what it was executed against. Log the browser name and version of every instance next to the 'Running test' line instead, that one always ends up in the torture log of the run.

• damencho(27 Aug 26)

  test(media) check that remote video is actually decoded after unmute The video mute state is signalled over the presence, so the existing checks pass as long as the icon disappears, and waitForSendReceiveData only looks at the bitrate. A sender that uses a payload type which was not negotiated (see lib-jitsi-meet#3095, Firefox sending VP9 in p2p) keeps the bitrate positive while the receiver decodes zero frames, so none of these checks notice it. Add Participant.waitForRemoteVideoDecoding() which waits for a positive framerate for the video of a remote endpoint and use it in the two two-party video specs after a camera unmute.

• Daksh Hiran(26 Aug 26)

  fix(base/popover): check contextMenuRef in outside click handler (#15559)

• Daksh Hiran(26 Aug 26)

  fix(base/responsive-ui): add hysteresis to aspect ratio to prevent layout thrashing (#17741)

• Alok-work23(27 Aug 26)

  feat(chat): add support for moderator message deletion (XEP-0425) (#17610) * feat(chat): Implemented moderator message deletion using XEP-0425 * feat(chat): updated message deletion apperance

• damencho(26 Aug 26)

  test(codec-selection): expect VP9 from Firefox 151+ Firefox supports VP9 encode from version 151 onwards, so lib-jitsi-meet no longer pushes VP9 to the bottom of the codec preference order for it (see https://bugzilla.mozilla.org/show_bug.cgi?id=1633876). After the grid was updated to Firefox 154, p1 in the ff-chrome run started encoding VP9 and the asymmetric codec assertions, which unconditionally expected VP8 on Firefox, began failing on every run. Gate the expected codec on the browser version instead, and interpolate the codec into the waitForCodec timeout message, which hardcoded VP8 and made the failure look like a VP8 problem.

• bgrozev(26 Aug 26)

  fix(prosody): do not rate limit s2s sessions (#17739) mod_rate_limit exempted only outgoing s2s, through session.outgoing. Incoming s2s was rate limited. A burst of presence stanzas on the link between the main prosody and a visitor node could thus throttle that link to the session rate for the full timeout. s2s is restricted to the hosts in s2s_whitelist, so a rate limit adds no protection there. Check session.base_type instead. util.session sets it when it creates the session and never changes it, and it covers both directions of s2s. The old check was also unreliable, because mod_s2s_bidi sets session.outgoing on incoming bidi sessions.