Don't update the participant list when only you joined

[nickvergessen]

Signed-off-by: Joas Schilling coding@schilljs.com

[nickvergessen]

/backport to stable23

[danxuliu]

When you receive the join event from the external signaling server after you joined a room I would still emit the participantListChanged, as the participant list indeed changed (participant list as the concept, not the Vue component), but with an extra parameter to know if it is a "self-join" (which could be just the list of joined users) so it can be ignored if not needed. That is, I would move the deciding logic from the signaling to the getParticipants mixin, as it is the one that fetches the participants when joining a conversation and thus the one that knows that it is not needed to fetch them again.

Nevertheless, the approach in this pull request (or the extra parameter) only prevents an extra request to the server after joining if no other user is in the room. If you join a room in which there are other users the external signaling server will send a join event about your own participant to all the participants in the room (including you) and another join event sent just to you with all the other participants (that is, excluding you). Although the events are published in that order they arrive in reverse order (the first event goes through the NAT and the second is sent directly, I guess it is what causes that), although I am not sure if that would always happen.

Due to this a different approach could be to pass the list of joined sessions in the participantListChanged* (with a parameter to know that they were added and not changed or removed) and check in the getParticipants mixin if all the joined sessions are already in the participants data to fetch it again or not. Although this might require to queue the checks if the participant data is being fetched to prevent deciding based on stalled data... (for example, if a participant leaves and quickly joins again with different parameters, like the status). So maybe it is better to improve all this at a later point and for now just remove the request for your own join 🤷

*Or listen to usersJoined, usersChanged and usersLeft rather than participantListChanged when the external signaling server is used.

[nickvergessen]

So maybe it is better to improve all this at a later point and for now just remove the request for your own join shrug

Which is exactly what I was trying to do. Simplicity and still removing a refresh.

[danxuliu]

Which is exactly what I was trying to do. Simplicity and still removing a refresh.

Fine by me 👍 Nevertheless, my comment about moving the logic from the signaling object to the getParticipant mixin still stands :-)

[nickvergessen]

my comment about moving the logic from the signaling object to the getParticipant mixin still stands :-)

Well the participant list didn't change, we updated it already with the response of our own join. But sure, let's continue emitting a false event and modify all listeners to ignore it instead of not emitting it

[nickvergessen]

Because the other listeners also reload the room information I don't dare to touch them just yet. So ready for review

[danxuliu]

I thought that the joinedUsers array provided the Nextcloud session id, so what I meant was just calling this._trigger('participantListChanged', { joined: joinedUsers }) from signaling.js and then ignoring the update in getParticipants.js if participants?.joined?.find(joinedParticipant => joinedParticipant.nextcloudSessionId === this.participant.sessionId. But joinedUsers only provides the signaling session ID, not the Nextcloud session ID, so the current participant can not be matched 🤷

Due to this I agree to use just the original commit, so I dropped the second commit that emitted whether the participant list was dirty or not, as the event logic is still coupled to the getParticipants mixin (and others) and moving the check does not provide a benefit; the other listeners of participantListChanged event (FilesSidebarTabApp, PublicShareAuthSidebar and PublicShareSidebar) do not need to listen to the event when self-joined either.

Tested and works 👍

[fancycode]

But joinedUsers only provides the signaling session ID, not the Nextcloud session ID, so the current participant can not be matched

FYI, this will change with the next release of the signaling server: strukturag/nextcloud-spreed-signaling#178