If the ID of a remote participant was the same as the ID of the local
participant (across multiple conferences), removing the remote
participant on PARTICIPANT_LEFT would remove the local participant.
Like the preceding commit "ref(base/conference): clear the 'conference'
field on WILL_LEAVE", this commit is part of the story how we are to
deal with conferences which take noticeable time to leave.
Like the preceding commit "ref(base/conference): clear the 'conference'
field on WILL_LEAVE", this commit is part of the story how we are to
deal with conferences which take noticeable time to leave.
If a leave is delayed and the leaving JitsiConference manages to sneak a
PARTICIPANT_JOINED in, it may create a remote participant who even
collides with the local participant.
With so many abstractions called conference, I'm not surprised I made a
mistake and my reviewer didn't catch it.
As we are transitioning from remote participants identified by ID alone
to an ID-conference pair, the subsequent commits "Protect against late
PARTICIPANT_JOINED" and "Refine PARTICIPANT_LEFT for ID collisions"
caught the error.
ref(base/conference): clear the 'conference' field on WILL_LEAVE
Pawel Domas said:
The conference state field is referring to the current conference in
progress, so it feels like this field should be cleared as soon as we
declare that the conference is being left and the asynchronous process
of leaving the conference starts (which happens on
CONFERENCE_WILL_LEAVE).
Lyubo Marinov said:
Merely setting conference to undefined is incomplete because there are
other redux state properties associated with conference.
What we're doing here is redefining the redux action
CONFERENCE_WILL_LEAVE:
The redux action CONFERENCE_WILL_LEAVE represents the order of the user
to leave a JitsiConference instance. From the user's perspective, there's
no going back (with respect to the instance itself). The app will perform
due clean-up like leaving the associated room, but the instance is no
longer the focus of the attention of the user and, consequently, the app.
Now CONFERENCE_LEFT and CONFERENCE_WILL_LEAVE have more in common than
before and we can do a much better job by expressing the common parts in
source code. Additionally, our source code can be rewritten to better
express the meaning of any of these two actions.
Co-authored-by: Pawel Domas <pawel.domas@jitsi.org>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>
Add ability to provide a display name in the configOverwrite object that
when available it will be used to customize the name of the meeting in
callkit screen and recent call list.
Co-authored-by: Daniel Ornelas <daniel.ob64@gmail.com>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>
This zOrder change fixes the issue that the scrollable filmstrip videos
rendered in front of the local participant, however there is still an
issue that needs to be fixed later: The rendered videos should have
overflow: 'hidden' property applied so then they don't get rendered when
scrolled out of the ScrollView, that property however doesn't seem to
work for Video components.
This fix is based on storing the location URL object we are loading the
configuration for in the redux store. Once the config has been loaded (or it has
failed, for that matter!) we'll check if the current "config URL" is the same we
set, and discard the old one if they don't match.
[RN] Fix a "TypeError: Cannot read property handlers of undefined" in ImageCache
With some of the preceding commits in the "multiplying remote
thumbnails" story line, I started hitting this error with 100%
reproducibility:
1. Have a remote participant prepared in conferenceA. Web will do as
well.
2. On iOS prepare to join conferenceB in Safari and use the same device
for step 3.
3. Join conferenceA on the iOS device from step 2 with audio-only. The
audio-only is so that avatars are always visible. Wait for the remote
participant prepared in step 1 to appear.
4. Switch to Safari and hit "Continue in the app" to have the app leave
conferenceA and join conferenceB.
What happens:
After the iOS device joins conferenceB in the Jitsi Meet app, the local
participant is on the large video (as expected) but the avatar of the
local participant is the default audo-generated auto-colored
placeholder. That's because this error was hit and the avatar couldn't
be "fetched".
Remove remote participants who are no longer of interest
The Jitsi Meet app always has at most 1 conference of primary interest.
It may have to juggle with 2 JitsiConference instances at the same time
if 1 is in the process of being left and one is joining/joined. But the
one which is joining or joined (which we call conference in the
features/base/conference redux state) is the one "of interest", the
other one is "clean up". Consequently, the remote participants of the
conference "of interest" are the remote participants "of interest" and
the others are "clean up". In order to reduce the time during which
there may be multiplying remote thumbnails, clean the remote
participants who are no longer "of interest" up.
Reduce direct read access to the features/base/participants redux state
As part of the work on fixing the problem with the multiplying
thumbnails, we've associated remote participant w/ JitsiConference.
However, there are periods of time when multiple JitsiConferences are in
the redux state (and that period is going to be shorted by
StateListenerRegistry). In order to give more control to the feature
base/participants, reduce the occurrences of direct access to the
features/base/participants redux state and utilize the feature's
existing read access functions. Which will allow us in the future to
enhance these functions to access participants which are relevant to the
current conference of interest to the user only.
The commit message of "Associate remote participant w/ JitsiConference
(_JOINED)" explains the motivation for this commit.
Practically, _JOINED and _LEFT combined with "Remove remote participants
who are no longer of interest" should alleviate the problem with
multiplying remote participants to an acceptable level of annoyance.
Technically though, a remote participant cannot be identified by an ID
only. The ID is (somewhat) "unique" in the context of a single
JitsiConference instance. So in order to not have to scratch our heads
over an obscure corner, racing case, it's better to always identify
remote participants by the pair id-conference. Unfortunately, that's a
bit of a high order given the existing source code. So I've implemented
the cases which are the easiest so that new source code written with
participantUpdated is more likely to identify a remote participant with
the pair id-conference.
Additionally, the commit "Reduce direct read access to the
features/base/participants redux state" brings more control back to the
functions of the feature base/participants so that one day we can (if we
choose to) do something like, for example:
If getParticipants is called with a conference, it returns the
participants from features/base/participants who are associated with the
specified conference. If no conference is specified in the function
call, then default to the conference which is the primary focus of the
app at the time of the function call. Added to the above, this should
allow us to further reduce the cases in which we're identifying remote
participants by id only and get us even closer to a more "predictable"
behavior in corner, racing cases.
The plan set in motion here is to associate remote participants with the
JitsiConference instances that created them in order to be able to
remove remote participants when a JitsiConference is no longer the
primary focus of the jitsi-meet app. And that's supposed to alleviate a
problem with multiplying remote thumbnails.
Doing all of the above in a single commit is a bit of a high order. So
I'm splitting the whole into multiple successive commits for the
purposes of observability, comprehension. Each commit is supposed to be
safe even if subsequent commits are not accepted, are reverted,
whatever. Obviously, without the successive commits, a commit may be
"unused".
One of the important pieces of the multiplying remote thumbnails "fix"
offered is removing remote participants who are no longer of interest
i.e. PARTICIPANT_LEFT. But in order for _LEFT to be implemented, _JOINED
must be implemented first.
Because a conference can fail before or after it's joined it must be
"left" in order to release any allocated resources like peerconnections,
tracks and all the other things.
- add 10px of padding on the sizes of the toolbar
- make the button margin smaller (from 10 to 7)
- increate the secondary button factor to 85%, thus rising the maximum secondary
button size to 50 (from the previous 48)
[RN] Set the local user ID on CONFERENCE_WILL_JOIN
Doing so in CONFERENCE_JOINED is too late because if we are moderators that
event will come first and we won't know what ID to match it with.
This is safe because our local ID is created early.
Lyubo Marinov
paweldomas
Daniel Ornelas
Bettenbuk Zoltan
hristoterezov
Saúl Ibarra Corretgé
virtuacoplenny