-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(chat) add support for sending and receiving reactions #2553
Conversation
he-patrick
commented
Aug 10, 2024
•
edited
Loading
edited
- build and send xml package in sendReaction
- process received reactions in onMessage
- emit event for frontend to update UI
…on check. (jitsi#2546) * ref(QualityController) Add recovery mechanism and adjust the resolution check. Impl a recovery mechanism for the lastN to be increased if the cpu limitation goes away and doesn't return after increasing lastN. Also, additionally improve the calculation of the expected resolution taking simulcast stream resolutions into account. * squash: Address review comments and add more unit tests * squash: Address review comments
It has been broken for over 3 years now, since jitsi@ca325f5#diff-9e19da30f465ca5665ac3d7ca1aa03d0498aed1be0cb2d7eeb27684a2636da77 Ever since that change, the "audioLevelReportHistory" property is not populated, so it justs acts on nothing an generates bogus log lines such as: ``` [modules/statistics/AudioOutputProblemDetector.js] A potential problem is detected with the audio output for participant b5fb30bc, local audio levels: [null,null], remote audio levels: undefined ``` Since nobody seems to have noticed in 3 years it's safe to assume we don't need this at all, so it gets the axe treatment.
When WebRTC ICE gathering policy is set to gather once instead of continually, the controlling agent goes to completed instead of connected (no more candidates to check). This doesn't happen in Chrome or other browsers, but is reproducible with node.js wrapper around WebRTC which runs with the default settings. This is causing a bug where the initiator side of a P2P connection does not fully switch to P2P mode and keeps on sending data on both P2P and JVB connections.
Hi, thanks for your contribution! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I remove receiverId since the reactions that are attached to private messages will not be visible to others anyways?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, because we want the sender to decide to whom a reaction should be sent.
Jenkins please test this please. |
@he-patrick I noticed you put the PR as a draft. Is there something missing? |
Should be ready now. |
Can you please rebase? |
I'm seeing that it's already up to date with master |