- We were sending one websocket message for each removed shape, send only one with all IDs.
- The shape limit verification was not always working with rapid updates and if somehow the db got more shapes,
the users couldn't update or delete any shape anymore
- Unnecessary remove shape messages were being sent to the server when going over limit
When a shape is changed, the full shape objcect was being transmitted to the server again.
Do a diff to only send what changed (similarly as it was in tldraw v1) to save upload bw.
TODO:
Draw segments diffs (array) is still not working, so all the segments are still being sent every time.
* Batch shapes and persist on idle or editing states
* add highlight.idle to condition
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
---------
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
Background shape can show white borders due to rounding erros in the tldraw canvas, change size and position of background shape to avoid it.
Also disable tl container outline showing when in focus.
* fix(dark-theme): adjust Dark Reader CSS selectors
Clean up inverted css selectors passed to Dark Reader and add new ones
for elements not correctly transformed to dark theme. These include the
tldraw color picker, text shape color, selected color indicator, tool
opacity slider, and camera dock background.
* Suggestions from review
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
* Suggestions from review
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
* Suggestions from review
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
* changes requested in review
* changes requested in review
---------
Co-authored-by: germanocaumo <germanocaumo@gmail.com>
In BBB 3.0, a change was made to collect full WebRTC stats continuously.
This method gathers stats from *all* peers and *all* senders and receivers
every 2 seconds. Originally, it was intended to run only when the user opened
the connection status dialog, providing in-depth info in the UI and making it
available for copying.
This new behavior is not ideal. Running full stats collection every 2 seconds
in meetings with 20+ peers/transceivers wastes client resources since the
collected data is unused 99% of the time.
This commit reverts to the pre-3.0 behavior (≤2.7), where full stats collection
(`startNetworkMonitoring`) runs only when the connection status modal is open.
As a bonus, it fixes the packet loss status transition log to use the packet
loss percentage, which is the actual trigger metric.
* restores react18 createRoot
* fix slideChange issue - new slide not loading
* fix skip video preview
* test: update screenshare function checks + close notifications
---------
Co-authored-by: Anton B <antonbsa.bck@gmail.com>
* fixing whiteboard tests
* fix undo whiteboard test
* finished updating whiteboard tests
* updated two tests
* updated all whiteboard screenshots, pan test is flaky
* changing whiteboard checks
* whiteboard tests updated
* rm screenshots from failing tests
* changed repeat code to be in a function
* change data-shape-type
* changed selector
* skip check for screenshot on ci
* changes on function name
* adding @ci to all test specs
* removed tag on unecessary test
When `muteOnStart=true`, the initial local mute state in AudioManager is
desynced from the server. This issue stems from two recent changes:
- Decoupling voice activity updates from the main user_voice subscription,
which introduced an implicit muted state placeholder value
of true instead of false. See user_voice_activity's DB schema
propagation rules.
- Introduction of dialplan-level muteOnStart, muting channels on creation
rather than after.
Without properly updating AudioManager's `isMuted` placeholder, no
user_voice_activity update triggers *when joining audio* with
muteOnStart=true, causing two issues:
- Sender tracks are not locally muted on audio join.
- Opening the audio settings modal while muted will cause the
microphone to be incorrectly *unmuted* once it's closed (first try only).
This fix sets AudioManager's `isMuted` placeholder to true, matching the
server. Additionally:
- Enforce the local mute state before joining audio to ensure the desired
sender track state. Should make this a bit more future proof.
- Track `user_voice_activity` before joining audio (rather than after)
to avoid race conditions.
- Clean up `AudioManager.init` (loadBridges no longer returns a promise etc).
The merge of 2.7 code into 3.0 dropped a change which was part of a fix
to prevent a recording processing hang when processing deskshare streams
which contain audio. Re-apply that change.
