Skip to content
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

Merged
merged 19 commits into from
Aug 12, 2024

Conversation

he-patrick
Copy link
Contributor

@he-patrick he-patrick commented Aug 10, 2024

  • build and send xml package in sendReaction
  • process received reactions in onMessage
  • emit event for frontend to update UI

he-patrick and others added 16 commits June 25, 2024 09:05
…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.
@jitsi-jenkins
Copy link

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

Copy link
Contributor Author

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?

Copy link
Member

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.

@saghul
Copy link
Member

saghul commented Aug 12, 2024

Jenkins please test this please.

@saghul
Copy link
Member

saghul commented Aug 12, 2024

@he-patrick I noticed you put the PR as a draft. Is there something missing?

@he-patrick he-patrick marked this pull request as ready for review August 12, 2024 12:53
@he-patrick
Copy link
Contributor Author

Should be ready now.

@saghul
Copy link
Member

saghul commented Aug 12, 2024

Can you please rebase?

@he-patrick
Copy link
Contributor Author

I'm seeing that it's already up to date with master

@saghul saghul merged commit 03f7d88 into jitsi:master Aug 12, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants