BaseApp does all the heavy-lifting related to creating the redux store,
navigation, and so on.
App currently handles URL props and actually triggering navigation based on
them.
Move it away from AbstractApp into an auxiliary function. In addition, introduce
a new `getServerURL` function which gets the configured server URL and defaults
to meet.jit.si as before.
It was never used in practice, and it would be very cumbersome to use, since it
would have to bcreated with all the middlewares and reducers we need. After
discussing this with Lyubomir, we are confident this is not going to be needed
so it can go.
Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.
This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.
In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:
- JitsiMeetJS initialization is now synchronous: there is nothing async about
it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
support can now be detected immediately, so take advantage of this to simplify
how we handle unsupported browsers. See [0].
The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.
[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779
* fix(connection): reload immediately on possible split-brain
There isn't an explicit way to know when a split brain
scenario has happened. It is assumed it arises when an
"item-not-found" connection error is encountered early
on in the conference. So, store when a connection has
happened so it be calculated how much time has
elapsed and if the threshold has not been exceeded
then do an immediate reload of the app instead of
showing the overlay with a reload timer.
* squash: rename isItemNotFoundError -> isShardChangedError
This commit adds a state getter that considers checking the enabled/disabled state of the calendar feature, so then other features don’t have to do it manually.
Adds a fatal error state on which will depend whether or not the reload
screen is to be displayed. It is to happen when a relevant fatal error
action is not claimed by any feature for error recovery (the recoverable
flag is not set).
- Instead of having 4 listeners for local connection status
updates and 1 for remote, remove two of the redundant listeners.
- Instead of calling into 4 separate VideoLayout methods to update a
participant's connection status, expose one handler.
Up until now, mobile was oblivious to participants' presence state. Presence
state handling is required (probably, amongst other things) for "call flows".
So, let's add it! This is done by gathering the presence state when a
participant first joins, and handling subsequent changes.
Fix the "mute ping pong" for once and for all. This patch takes a new approach
to the problem: it keeps track of the user generated CallKit transaction ations
and avoids calling the delegate method in those cases.
This results in a much cleaner and easier to understand handling of the flow: if
the delegate method is called it means the user tapped on the mute button. When
we sync the muted state in JS with CallKit the delegate method won't be called
at all, thus avoiding the ping-pong altogether.
In addition, make sure all CallKit methods run in the UI thread. CallKit will
call our delegate methods in the UI thread too, thsu there is no need to
synchronize access to the listener / pending action sets.
* feat(settings): setting dialog
- Move device selection, profile edit, language select, moderator
options, and server auth into one modal with tabs.
- Remove side panel profile and settings and logic used to update
them.
- Pipe server auth status into redux to display in the settings
dialog.
- Change filmstrip only device selection popup to use the new
stateless settings dialog component.
* squash: do not show profile tab if not guest
* squash: profile button not clickable if no profile to show
* squash: nits
* ref: Settings dialog.
Emits CONFERENCE_FAILED in response to CONNECTION_FAILED event
which then triggers JitsiConference.leave() through the middleware
processing. Also base/conference state will be adjusted. It is to have
a consistent redux state in which both connection and conference are
failed. It could happen that in a buggy environment the XMPP connection
is dropped, but the media is still flowing which would result in weird
user experience.
The change to mobile/external-api is required to not emit
CONFERENCE_FAILED for CONNECTION_FAILED if the conference has been
started, because base/conference state will still hold conference
instances which are to be ended by other means and result in the
appropriate event (which will adjust the base/conference state).
Currently the listeners for disconnected and failed connection events
are unsubscribed as soon as the connection is established, so
the CONNECTION_DISCONNECTED is never triggered which would clear the
'connection' field. This commit will clear the 'connection' state on
CONNECTION_WILL_CONNECT. It's needed anyway given that there's no
guarantee on when and if the async disconnect operation will finish.
One issue caused by the 'connection' not cleared was that
CONNECTION_FAILED was not reduced correctly and the reload screen was
not displayed for the following scenario:
1. Join and leave any working conference.
2. Turn off network connectivity on the device.
3. Wait for CONNECTION_FAILED. The reload screen will not be displayed,
because CONNECTION_FAILED is not reduced correctly, because the old
'connection' value is still there.
Your truly introduced this regression in
8c7a3f16b1, alas.
The audio only mode is used to set the CallKit call type. This affects the
behavior on the recent calls entries (calls are marked either as audio or video
calls).
Sync both at the start and for transitions. The previous code was working by
chance (in a way): when the CallKit UI is presented the local video is muted,
which triggers a SET_VIDEO_MUTED action, at which point the audio-only mode was
checked for. Now we are more explicit and act on SET_AUDIO_MUTED.
Read the muted state from the track itself instead of from base/media. This
avoid expressing the incorrect desire when the call starts muted because
permission was never granted.
In the current middleware logic, when the local participant becomes
dominant speaker, a new participant can be selected to receive
high quality video from. This means large-video could potentially
do a switch to another participant when the local participant
becomes dominant speaker. Prevent such behavior.
* Adds an option to disable features based on token data.
Reverts changes from b84e910086, removes disableDesktopSharing option and an interface_config option.
* Disable recording button based on token features data.
Hide recording if local participant isGuest and roles based on token.
When enableUserRolesBasedOnToken is enabled we were not hiding the record button for guests.
* Adds filtering of jibri iqs and rayo based on features.
Moves feature checking in separate utility function.
Renames utility method.
* Adds a footer text when outbound-call is not feature enabled.
* Fixes comments.
Use it unless the connection is not ACTIVE. We don't really care if it's
recovering or whatever, if it's not active it has problems, so that's that.
This fixes a potential edge case in which the connection remains in RESTORING
state for some time.
* ref(toolbar): show recording features based on explicit configs
* squash: bring back button configs, use final config names
* squash: update interfaceConfig comment, remove unused config whitelist
* squash: change order of button enabled checks to reduce diff
* squash: fileRecording -> fileRecordings
* feat(recording): add sounds for when recording starts and stops
* squash: use constants, play sounds for file only
* squash: rename recordingStopped.mp3 -> recordingOff.mp3
* squash: flip var declaration for alpha order
Layout:
Use an absolute-fill view as the background with the sidebar on top of. This
greatly simplifies styling, as there is no need to calculate how large the
backdrop needs to be.
Animation:
Switch to a translateX transform animation. This serves 2 purposes: first,
there seems to be a bug somewhere in React Native 0.51-0.55 where the content
that is being animated starts to be clipped. Very weird! But more importantly,
translateX transmorm animations are supported by the native animation driver!
https://facebook.github.io/react-native/blog/2017/02/14/using-native-driver-for-animated.html8f5ebe5952/Libraries/Animated/src/NativeAnimatedHelper.js (L138-L176)
This makes the animation more performant and buttery smooth.
Some small cleanups are also included here.
Instead of keeping dominant speaker locally, get it from redux and be
updated when the dominant speaker changes. This is in an attempt to mimic
the video layout being reactified and connected to redux.
The visibility of the toolbar can be toggled by interacting with the main screen.
This change allows the toolbar to be configured to be 'always visible'. This voids
the 'toggle' functionality.
Simplify parts of the logic introduced in
11b7144ad0.
Specificaly, using all the state change avoiding functions doesn't give us much
since we need to copy the state for sure.
Makes sure that whenever a conference is left or switched, the local
participant's id will be equal to the default value.
The problem fixed by this commit is a situation where the local
participant may end up sharing the same ID with it's "ghost" when
rejoining a disconnected conference. The most important and easiest to
hit case is when the conference is left after the CONFERENCE_FAILED
event.
Another rare and harder to encounter in the real world issue is
where CONFERENCE_LEFT may come with the delay due to it's asynchronous
nature. The step by step scenario is as follows: trying to leave a
conference, but the network is not doing well, so it takes time,
requests are timing out. After getting back to the welcome page the
the CONFERENCE_LEFT has not arrived yet. The same conference is joined
again and the load config may timeout, but it will be read from the
cache. Now the network gets better and conference is joining which
results in our ghost participant added to the redux state. At this point
there's the root issue: two participants with the same id, because the
local one was neither cleared nor set to the new one yet
(PARTICIPANT_JOINED come, before CONFERENCE_JOINED where we adjust the
id). Then comes CONFERENCE_JOINED and we try to update our local id.
We're updating the ID of both ghost and local participant. It could be
also that the delayed CONFERENCE_LEFT comes for the old conference, but
it's too late and it would update the id for both participants.
The approach here reasons that the ID of the local participant
may be reset as soon as the local participant and, respectively, her ID
is no longer involved in a recoverable JitsiConference of interest to
the user and, consequently, the app.
Co-authored-by: Pawel Domas <pawel.domas@jitsi.org>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>
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.
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.
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".
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.
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)
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.
* feat(recording): frontend logic can support live streaming and recording
Instead of either live streaming or recording, now both can live together. The
changes to facilitate such include the following:
- Killing the state storing in Recording.js. Instead state is stored in the lib
and updated in redux for labels to display the necessary state updates.
- Creating a new container, Labels, for recording labels. Previously labels were
manually created and positioned. The container can create a reasonable number
of labels and only the container itself needs to be positioned with CSS. The
VideoQualityLabel has been shoved into the container as well because it moves
along with the recording labels.
- The action for updating recording state has been modified to enable updating
an array of recording sessions to support having multiple sessions.
- Confirmation dialogs for stopping and starting a file recording session have
been created, as they previously were jquery modals opened by Recording.js.
- Toolbox.web displays live streaming and recording buttons based on
configuration instead of recording availability.
- VideoQualityLabel and RecordingLabel have been simplified to remove any
positioning logic, as the Labels container handles such.
- Previous recording state update logic has been moved into the RecordingLabel
component. Each RecordingLabel is in charge of displaying state for a
recording session. The display UX has been left alone.
- Sipgw availability is no longer broadcast so remove logic depending on its
state. Some moving around of code was necessary to get around linting errors
about the existing code being too deeply nested (even though I didn't touch
it).
* work around lib-jitsi-meet circular dependency issues
* refactor labels to use html base
* pass in translation keys to video quality label
* add video quality classnames for torture tests
* break up, rearrange recorder session update listener
* add comment about disabling startup resize animation
* rename session to sessionData
* chore(deps): update to latest lib for recording changes
Contributing all buttons in one place goes against the designs that we
set out at the beginning of the project's rewrite and that multiple of
us have been following since then.
Currently the following are implemented:
- AudioMuteButton
- HangupButton
- VideoMuteButton
In order to implement these new buttons a new abstract class was introduced,
which abstracts the ToolboxItem into a button with enough hooks so a stateful
and a stateless version of it can be created.
This patch only adds the stateful implementation of the aforementioned buttons.
This abstraction represents an action which can go anywhere in a toolbox (be
that the main toolbar or the overflow menu) and it's platform independent.
It does not depend on Redux, thus making it stateless, which facilitates its use
in stateful button implementations as well as stateless ones.
Knowledge is power, man!
The config.js cache predates the feature base/known-domains.
Technically, it's also able to recall more domains that the feature
recent-list can (because the latter limits its entries).
Knowledge is power, man!
We moved "knownDomains" from calendar-sync to base/known-domains.
However, we do have an official release in the app stores and I'd like
us to not throw away the knowledge it has acquired.
If multiple JitsiMeetView instances are created (not necessarily
existing at once), it's possible to hit a TypeError when reading the
React Component props of the currently mounted App. Anyway, in certain
places we're already protecting against that out of abundance of caution
so it makes no sense to not protect everywhere.
Make it more generic by accepting any content except of just rows with text and
icons.
In addition, rework its structure so the animation is smoother, by putting the
background overlay outside of the Modal. This way, the animation doesn't affect
the background, which won't slide down.
* fix(toolbar): make button hover bigger
* fix(toolbar): make hangup button bigger
* fix(always-on-top): make toolbar and buttons same sizes as main toolbar
* fix(toolbar): change some tooltips
* fix(toolbar): adjust side panel and filmstrip for new toolbar sizes
It seems that the external API will not send any event to let the sdk
consumer know that the conference has failed if the problem occurs at
the establishing of XMPP connection stage. That's because the config was
loaded successfully, but the conference instance does not exist yet, so
neither base/config nor base/conference will emit any failure.
Make the external API emit CONFERENCE_WILL_JOIN early on SET_ROOM action
which occurs before the XMPP connection is created. At this point we
know that config has loaded and if there's a valid conference room to
be joined. We were thinking of doing that even on CONFIG_WILL_LOAD,
but that seemed to be to risky at this point.
With this the RN component and the consumer app can share same CallKit
provider, configuration, and enable to be part of multiple listeners of
the CallKit flow events. The main driver of this is to enable the
consumer app to be able to report an incoming call to the OS before
loading the JitsiMeetView. Once the user answers the call, the app can
instantiate a JitsiMeetView, pass the CallKit call UUIID, and the Jitsi
Meet components will handle the connection and report back to CallKit
that the call has been established.
Hristo Terezov, Chris Cordle, and I/Lyubomir Marinov agreed that we'd
try to use "invite" & "invitee(s)" in Web/React's iframe API,
mobile/react-native's SDK invite API, and internally for the purposes of
consistency, ease of understanding, etc.
This can happen if there are multiple JitsiMeetView instances are active at the
same time, because there is a single bridge, which means all of them would get
the events.
Currently enterPictureInPicture action can only be dispatched when
the app is on the conference view and the enter PiP button is displayed,
so no check should be necessary.
Activity.enterPictureInPictureMode method must be invoked synchronously
on userLeaveHint callback in order to be sure that the current Activity
is still visible (does not transit to PAUSED state). Previously if the
asynchronous processing would be delayed enough for the Activity to go
into the PAUSED state it will be too late to go into the PiP mode.
To reduce the amount of motion that has to be blurred, use a canvas
to essentially set the FPS of the video background. This canvas
component is behind a temporary feature flag, as well as being able
to disable the blur, so it can be played around with on deployed
environments.
- Update font files to add new icon.
- Update markup and style so the icon has a small background
to fill in the text of the icon.
- Remove some css transitions that don't seem to do much.
In order to be able to add analytics to the deep-linking pages the
lib-jitsi-meet initialization has been moved so it happens earlier.
The introduced `initPromise` will eventually disappear, once conference is
migrated into React and / or support for Temasys is dropped. At that stage, it
can be turned into a sync function which all platforms share.
* Button conditionally shown based on if the feature is enabled and available
* Hooks for launching the invite UI (delegates to the native layer)
* Hooks for using the search and dial out checks from the native layer (calls back into JS)
* Hooks for handling sending invites and passing any failures back to the native layer
* Android and iOS handling for those hooks
Author: Ryan Peck <rpeck@atlassian.com>
Author: Eric Brynsvold <ebrynsvold@atlassian.com>
* Adds in memory log storage, to be used while testing.
Enabling it only when config.debug is set, a configuration provided by jitsi-meet-torture.
* Moves to using config.testing.testMode property for logs storage.
* Fixes comments.
Activity.enterPictureInPictureMode can fail for a couple of reasons
mentioned in the JSDoc:
"The system may disallow entering picture-in-picture in various cases,
including when the activity is not visible, if the screen is locked or
if the user has an activity pinned."
It seems to be safe to assume that those cases will be caught by
a RuntimeException handler (only RuntimeExceptions can be left without
explicit catch block).
Anyway the root cause for problems is the fact that the current process
for going to the picture in picture mode is not synchronised with
Activity's lifecycle. On Activity's "userLeaveHint" callback we dispatch
async task to the JS code which only then after dispatching some more
stuff eventually call native method that enter PiP. In case we spend too
much time on the JS side and the Activity goes to PAUSED state the call
will fail with IllegalStatException: "activity is not visible",
"activity is paused" etc. This means with this fix the app will not
crash, but we'll see it sometimes not go to the PiP mode as expected.
* feat(recording): show the YouTube live stream URL
- From the start live stream dialog, push up the broadcast ID
of the chosen broadcast. It is assumed the ID can be used to
create the YouTube link.
- Listen for lib-jitsi-meet to emit updates of the known live
stream URL, shove it into redux, and have InfoDialog display
it.
* ref(info): pass in dial in and live stream url
Passing these values in should trigger AtlasKit InlineDialog
to re-render and reposition itself.
* ref(info): use conference existence as trigger for autoshowing dialog
* feat(info): add live stream link to invite copy
* Revert "ref(info): use conference existence as trigger for autoshowing dialog"
This reverts commit 1072102267.
* hidden -> url
* _onClickHiddenURL -> _onClickURLText
Since the main conference container is no longer "clickable" there must
be a way for clicking on the "large video". A clickable TestHint nested
in ParticipantView makes it easier for dealing with the fact that the
click handler is not always on the same component (required for the
pinch and zoom feature to work correctly).
Allows to bind a click handler to a TestHint.
When a mobile test wants to click an UI element it must be able to
locate it through the accessibility layer. Now the problem with that is
that there is currently no uniform way for finding element on both iOS
and Android. This problem is solved by TestHint component which takes
an id parameter which then can be specified in the corresponding java
TestHint class in jitsi-meet-torture to easily find it. By being able to
add a click handler to a TestHint, it's possible to duplicate original
handler under nested TestHint and then find it easily on the torture
side.
Adds the logic to render TestHint only when the test mode is enabled
in order to be able to put independent TestHints in other places than
the TestConnectionInfo component.
Be explciit about the appearance we desire, since each mounted StaturBar
component will override the existing values. In this case, the problem was
caused because the default on iOS is dark, whereas it's light on Android.
Set it to light so it works consistently across both, which is what we want.
It's too sensitive and most of the time I cannot perform an onPress. In
contrast, the builtin/default/standard onPress is noticeably more
forgiving. While we fix the sensitivity of "pinch to zoom", don't use
its onPress unless absolutely necessary i.e. use it only for desktop
streams.
Zoltan Bettenbuk suggested the following:
const state = getState();
if (desiredTypes.length === 0) {
- const { audio, video } = state['features/base/media'];
-
- audio.muted || desiredTypes.push(MEDIA_TYPE.AUDIO);
- video.muted || desiredTypes.push(MEDIA_TYPE.VIDEO);
+ const startAudioOnly = getPropertyValue(state, 'startAudioOnly');
+ const startWithAudioMuted
+ = getPropertyValue(state, 'startWithAudioMuted');
+ const startWithVideoMuted
+ = getPropertyValue(state, 'startWithVideoMuted');
+
+ if (!startWithAudioMuted) {
+ desiredTypes.push(MEDIA_TYPE.AUDIO);
+ }
+ if (!startAudioOnly && !startWithVideoMuted) {
+ desiredTypes.push(MEDIA_TYPE.VIDEO);
+ }
}
const availableTypes
The final commit is really a different implementation of the same idea
but takes into account that the state of base/media already contains the
intent of the URL and notices the delay in the realization of the
background app state.
Additionally, unbreaks one more case where setAudioOnly is incorrectly
dispatched on CONFERENCE_LEFT or CONFERENCE_FAILED and, consequently,
overrides the intent of the URL.
* feat(Deeplinking): Implement for web.
* ref(unsupported_browser): Move the mobile version to deeplinking feature
* feat(deeplinking_mobile): Redesign.
* fix(deeplinking): Use interface.NATIVE_APP_NAME.
* feat(dial_in_summary): Add the PIN to the number link.
* fix(deep_linking): Handle use case when there isn't deep linking image.
* fix(deep_linking): css
* fix(deep_linking): deeplink -> "deep linking"
* fix(deeplinking_css): Remove position: fixed
* docs(deeplinking): Add comment for the openWebApp action.
* fix(recording): fetch events also for available broadcasts
Only "persistent" broadcasts were being fetched using the
YouTube API. Fetching "all" will get persistent broadcasts
and events. If events use a custom encoder then the stream
key can be obtained. If google hangouts is used for the event
then a stream key will not be obtainable; in those cases
input empty string as the stream key.
* squash: fix typos, reword comments, use object for preventing duplicate broadcasts
The feature was not ported to the new toolbar. Arguable these
can all be moved into notification but for now simply the
logic will be removed and worked on again as demand arised.
Adds TestConnectionInfo component which exposes some internal app state
to the jitsi-meet-torture through the UI accessibility layer. This
component will render only if config.testing.testMode is set to true.
Moves the statsEmitter.start() invocation to the middleware of
the connection-indicator feature, so that it's started for both mobile
and web (now mobile needs RTP stats for the tests).
On Android the files will be copied to the assets/sounds directory of
the SDK bundle on build time. To play the "asset:/" prefix has to be
used to locate the files correctly.
On iOS each sound file must be added to the SDK's Xcode project in order
to be bundled correctly. To playback we need to know the path of the SDK
bundle which is now exposed by the AppInfo iOS module.
TouchableWithoutFeedback and TouchableHighlight interfere with the
implementation of 'pinch to zoom' to come. We prepare for it by driving
the onClick/onPress handler(s) out of Conference, through LargeVideo and
ParticipantView into Video itself where the bulk of 'pinch to zoom' will
be implemented.
In preparation for "pinch to zoom" support in desktop streams on mobile, make
certain Views not intervene in touch event handling. While the modification is
necessary for "pinch to zoom" which is coming later, it really makes sense for
the modified Views to not be involved in touching because they're used to aid
layout and/or animations and are to behave to the user as if they're not there.
Adds Nat64InfoModule which resolves IPv6 addresses for IPv4 addresses
in IPv6 only network where jitsi-meet deployment does not provide any
IPv6 addresses as ICE candidates.
Being kicked out of the conference will result with a conference failed
event with 'conference.kicked' reason and take the user back to
the welcome page by navigating to 'undefined'.
I don't understand the old showDesktopSharingButton action
but I've tried my best to copy it over. There is an existing
issue where the keyboard shortcut gets registered when it
probably shouldn't because screensharing is disabled. It will
be fixed soon with refactoring of the entire logic determining
whether or not to show the screensharing button.
The onPresence parsing was refactored to remove use of jQuery.
This exposed three methods not available in react-native:
ParentNode.children, ChildNode.remove, and
document.querySelectorAll. The querySelectorAll change could
be swapped for the already polyfilled querySelector, but
children and remove had to be added. The polyfills are based
on those supplied by MDN web docs, but modified to pass jitsi
linting.
* fix(invite): do not send empty queries for people search
The endpoint might return an error if an empty query is sent.
* fix(invite): add error logging for failed people directory requests
The error currently being passed through from $.getJSON ended up
being an empty string plus was not getting logged. So switch to
fetch to move along with jquery killing and log the error.
* fix(dial-in): add error logging for failed requests
* ref(invite): create a fetch helper to remove duplicate logic
* feat(invite): add basic analytics for AddPeople dialog
Analytics for opening the dialog, closing the dialog, the
count of invites sent, and the count of invites errored.
* squash: fix typo, change default count init, remove extra analytics param
* feat(recording): use google api to get stream key
* squash: renaming pass
* squash: return full load promise
* sqush: use google api state enum
* squash: workaround for lib not loading
* another new design...
* increase timeout workaround for gapi load issue
* styling pass
* tweak copy
* squash: auto select first broadcast
Moves the things around to be able to override the config with the URL
params specified in the hash part of the location URI to which the app
is navigating to.
Adds base/sounds feature which allows other features to register a sound
source under specified id. A new SoundsCollection component will then
render corresponding HTMLAudioElement for each such sound. Once "setRef"
callback is called by the HTMLAudioElement, this element will be added
to the Redux store. When that happens sound can be played through the
new 'playSound' action which will call play() method on the stored
HTMLAudioElement instance.
Pre-existing logic made it so numbers were assumed as valid
if no validation url was specified. To be consistent with
the validation server, the faked number should include a
+ at the beginning.
* feat(invite): be able to call numbers from the invite dialog
The major changes:
- Remove DialOutDialog, its views, redux hooks, css, and images.
Its main functionality has been moved into AddPeopleDialog.
- Modify the AppPeopleDialog styling a bit so it is wider.
- Add phone numbers to AddPeopleDialog search results. Phone
numbers are validated in parallel with the request for people
and then appended to the result. The validation includes
an ajax to validate the number is recognized as dialable by
the server. The trigger for the validation is essentially if
the entered input is numbers only.
- AddPeopleDialog holds onto the full object representation of
an item selected in MultiSelectAutocomplete. This is so
selected items can be removed on successful invite, leaving
only unsuccessful items.
- More granular error handling on invite so individual invitees
can be removed from the selected items list.
* squash: change load state, new regex for numbers
* squash: change strings, auto prepend 1 if no country code, add reminders
* deps: update jquery version
* squash: resize thumbnails after appending shared thumb
This forces jquery animate to show the thumbnail somehow...
Remote thumbnails basically work this way (append to filmstrip
and then resize filmstrip thumbnails) so I just copied that
implementation. ... So I admit I lost this fight because
even after looking at jquery I couldn't understand why
it doesn't work on the first resize but does on the second.
Plus I'm being put on a strict timebox to update jquery.
* squash: getJSON no longer supports .success
The difference from this change and 88325ae is there is no
attempt to do this in redux. This is the safer change in that
the cleanup logic is known only to trigger on hangup.
This reverts commit 88325aeef2.
Turns out a conference with a password triggers a failed conference
join. It's going to be tricky to decipher when to do actual
cleanup, and where to shove that code, so reverting is easier for
now.
Recent changes in lib-jitsi-meet probably led to (1) our
RTCPeerConnection customizations on react-native not being used which is
a problem because we need them for at least NAT64 on iOS in order to
pass the review in Apple's App Store and (2) unexpected exceptions
inside react-native-webrtc.
The Promise-based WebRTC API should be merged from react-native-webrtc's
upstream but I don't want to do it right now because last time we got
multiple bugs in addition.
Destroy local tracks and also destroy large video so the
user does not wonder why camera (and mic) are still enabled
even though hangup has been pressed.
This only works automatically on Android >= 8. On other platforms / versions, it
relies on the SDK user on implementing a "reduced UI" mode and reacting to the
"request PIP" delegate method.
- Move the existing components for the static dial in page into
a separate folder for easier reuse.
- Reuse those components for displaying dial-on numbers on the
mobile page for unsupported browsers.
- Modify those components to support having tel protocol
links on the dial-in numbers.
- Have DialInSummary, formerly DialInInfoPage, respect a
passed in className prop for easier styling differences.
* ref(invite): remove InviteDialog
InviteDialog functionality has been moved into InfoDialog.
The InviteButton has been temporarily hacked to show one
of its dropdown options instead as the button. Future
work will bring in a redesigned InviteModal that the button
will open.
* squash: filter invalid options and map valid options
* squash: update strings
On Android we go into "immersive mode" when in a conference, this is our way of
being full-creen. There are occasions, however, in which Android takes us out of
immerfive mode without us (the application / SDK) knowing: when a child activity
is started, a modal window shown, etc.
In order to be resilient to any possible change in the immersive mode, register
a listener which will be called when Android changes it, so we can re-eavluate
if we need it and thus re-enable it.
* feat(info): new dialog design
- Add display of a dial in number.
- Add a static page to show a full list of dial in numbers.
- Add password management.
- Invite modal will be changed soon to remove password and
dial-in.
* squash: add classes for torture tests
* squash: class for local lock for torture tests
* squash: more classes for torture tests
* squash: more classes, work around linter
* squash: remove unused string?
* squash: work around linter and avoid react warnings
* squash: pixel push, add bold
* squash: font size bump
* squash: NumbersTable -> NumbersList
* squash: document response from fetching numbers
* squash: showEdit -> editEnabled, pixel push padding for alignment
* squash: pin -> conferenceID
* squash: prepare to receive defaultCountry from api
When in PiP mode the LargeView will not be large enough to hold the avatar (for
those interested in the details, our avatar's size is 200, and in PiP mode the
app is resized to about 150).
In order to solve it, this PR refactors how the avatar style is passed along,
reducing it to a single "size" prop. With this only prop, the Avatar compononent
will compute the width, height and borderRadius, plus deal with some Android
shenanigans.
In addition, the LargeView component now uses DimensionsDetector to check its
own size and adjust the size prop passed to the Avatar component as needed.
* ref(large-video): reactify background
This is pre-requisite work for disabling the background on
certain browsers, namely Firefox. By moving the component
to react, and in general encapsulating background logic,
selectively disabling the background will be easier.
The component was left for LargeVideo to update so it can
continue to coordinate update timing with the actual large
video display. If the background were moved completely into
react and redux with LargeVideo, then background updates would
occur before large video updates causing visual jank.
* fix(large-video): do not show background for Firefox and temasys
Firefox has performance issues with adding filter effects on
animated elements. On temasys, the background videos weren't
really displaying anyway.
* some props refactoring
Instead of passing in classes to LargeVideoBackground, rely on
explicit props. At some point LargeVideo will have to be reactified
and the relationsihp between it and LargeVideoBackground might
change, so for now make use of props to be explicit about
how LargeVideoBackground can be modified.
Also, set the jitsiTrack to display on LargeVideoBackground to
null if the background is not displayed. This was an existing
optimization, although previously done with pausing and playing.
* squash: use newly exposed RTCBrowserType
* squash: rebase and use new lib browser util
* squash: move hiding logic all into LargeVideo
* squash: remove hiding of background on stream change. hopefully doesnt break anything
Passing around of the component was used when there were two
independent Notification components. Now that there is only
one Notification component, it is not necessary to pass
around the component.
This is only implemented for mobile at the moment, since web doesn't handle
visibility within the Filmstrip component yet, so this should be added right
then, too.
* Handles connection failed event details (passing them to analytics).
* Fixing comments.
* Updates depending versions to be able to test.
* Fixing comments.
* Fixes wrong jsdoc.
We started on the way to responsive UI and its design with aspect ratio
and keeping the filmstrip on the short side of the app's visible
rectangle.
Shortly, we're going to introduce reduced UI for Picture-in-Picture. And
that's where we'll need another dimensions-based detector akin to the
aspect ratio detector.
While the AspectRatioDetector, the up-and-coming ReducedUIDetector, and
their base DimensionsDetector are definitely separate abstractions and
implementations not mixed for the purposes of easy extensibility and
maintenance, the three of them are our building blocks on top of which
we'll build our responsive UI.
Turns out this was a bit more involved than I originally thought due to an
interesting (corner) case: IFF the user was never asked about microphone
permissions and the call starts with audio muted, unmuting from the CallKit
interface won't work (iOS won't show the prompt, it fails immediately) and we
need to sync the mute state back.
If the view gets resized to a 1:1 aspect ratio, remember the previous mode to
avoid flickering when going back to a larger size or different aspect ratio.
If config.enableUserRolesBasedOnToken is true, only let moderators
and non-guests modify the password. Otherwise, only let moderators
edit the password.
Spot will need a way to submit call feedback using the iframe
api. For now expose a method on conference.js to submit that
feedback. Exposing on conference.js looks to be the existing
pattern... Also add an event to notify consumers of the iframe
api that feedback was submitted, as postMessage is async
and the notification can at least give some guarantee maybe.
I haven't updated documentation yet as I'm not confident
about this api.
Improve the experience when joining a room by removing the need to tap the join
button. The keyboard type has also been set to "go", which translated on the
builtin keyboard button label to be "go" (it's builtin, the operating system
translates it). This works on both Android and iOS.
Android uses a SurfaceView to render video, which is not quite a View, so the
fade-in animation (which varies the opacity) doesn't work.
Instead, add an opaque black view covering the video, which transitions to
transparent. This creates much smoother transitions on Android, while behaving
the same.
In addition, I removed the flip animation for local tracks, which is no longer
used, since the camera is switched without changing tracks.
* ref: Restructures the pinned/unpinned events.
* ref: Refactors the "audio only disabled" event.
* ref: Refactors the "stream switch delay" event.
* ref: Refactors the "select participant failed" event.
* ref: Refactors the "initially muted" events.
* ref: Refactors the screen sharing started/stopped events.
* ref: Restructures the "device list changed" events.
* ref: Restructures the "shared video" events.
* ref: Restructures the "start muted" events.
* ref: Restructures the "start audio only" event.
* ref: Restructures the "sync track state" event.
* ref: Restructures the "callkit" events.
* ref: Restructures the "replace track".
* ref: Restructures keyboard shortcuts events.
* ref: Restructures most of the toolbar events.
* ref: Refactors the API events.
* ref: Restructures the video quality, profile button and invite dialog events.
* ref: Refactors the "device changed" events.
* ref: Refactors the page reload event.
* ref: Removes an unused function.
* ref: Removes a method which is needlessly exposed under a different name.
* ref: Refactors the events from the remote video menu.
* ref: Refactors the events from the profile pane.
* ref: Restructures the recording-related events.
Removes events fired when recording with something other than jibri
(which isn't currently supported anyway).
* ref: Cleans up AnalyticsEvents.js.
* ref: Removes an unused function and adds documentation.
* feat: Adds events for all API calls.
* fix: Addresses feedback.
* fix: Brings back mistakenly removed code.
* fix: Simplifies code and fixes a bug in toggleFilmstrip
when the 'visible' parameter is defined.
* feat: Removes the resolution change application log.
* ref: Uses consistent naming for events' attributes.
Uses "_" as a separator instead of camel case or ".".
* ref: Don't add the user agent and conference name
as permanent properties. The library does this on its own now.
* ref: Adapts the GA handler to changes in lib-jitsi-meet.
* ref: Removes unused fields from the analytics handler initializaiton.
* ref: Renames the google analytics file and add docs.
* fix: Fixes the push-to-talk events and logs.
* npm: Updates lib-jitsi-meet to 515374c8d383cb17df8ed76427e6f0fb5ea6ff1e.
* fix: Fixes a recently introduced bug in the google analytics handler.
* ref: Uses "value" instead of "delay" since this is friendlier to GA.
There is more avatar work coming down the line for mobile,
which should also affect web, assuming the same getAvatarURL
helper will be used. As such, instead of continuing to
support the initials service and tweaking UI, revert to
make way for the future avatar work.
This reverts commit 2ea5ad68a5.
The inline classes for the toolbars were re-arranged
to fix non-rounded corners in the always-on-top window's
toolbar. However, those classes were also used by the
torture tests as a way to find stable elements that will
not get blown away by a react re-render. So re-wrap the
buttons with a div that will not get blown away,
add back the inline classes to those divs, and change
the CSS to round the corners in the always-on-top
window's toolbar.
* ref(avatars): remove Avatar.js
- Rely on redux getting updated with new participant state
and any calls to getAvatarURL passing in the redux
participant state. This way the state within Avatar.js can
be removed.
- Clean up methods on UI.js. Because all state is in the
store, separate methods for updating the avatar aren't as
necessary. Instead centralize accessing of the avatar for
components outside of redux and centralize the call to
update avatars for non-react components.
- Controversial: cache a participant's avatarURL on the
participant state. Currently the participant's avatarURL
that is generated without jwt (which sets the avatarURL directly)
is not cached. Without cache, there can be many redundant
calls to APP.API.notifyAvatarChanged.
* Leverage middleware timing to diff avatars
One alternative implementation is to leverage middleware's
ability to intercept updates before and after redux has
upated and then compare avatarURLs.
* kill UI.getAvatarUrl
* profile button sets its own avatar url (solves update timing)
* remove calls to updating avatar outside of middleware
* update UI.js doc
* remove left over logic from initial implementation
* try to move local user fallback into selector func
* default to id 'local' in selector
The video will switch to the avatar and be tinted with gray. On the large view,
a text message indicating the user has connectivity issues will be shown.
They will be stored in redux and the PageReloadOverlay will be displayed.
Note that this commit also introduces a subtle (and yet important!) change:
the location URL is now always set, regardless of the configuration loading or
not. This is needed in order for the retry logic to pick it up.
On web Conference is pretty much all there is, but on mobile we have the welcome
page and the blank page. If we fail to load config.js, for example we will still
be in the welcome page *and* we want to show an error overlay.
* Removes unused config logic.
* Whitelists config options that can be overridden using the URL.
* Recorder login with credentials, not supported by externalconnect.
Jibri uses xmpp credentials to login, which is not supported by externalconnect, so we want to skip it till that is supported.
* Whitelist only config.js
* Extracts whitelisting in separate function.
The goal is to reduce usage on atlassian/aui. New components
have been created to display the settings panel. Language
selection will reach into i18n for state whereas moderator
options will keep state in redux.
Properly handle errors while connecting or joining a conference. Prior to this
patch, only errors on established conferences / connections were saved to the
redux store.
75bf7638b3 introduced this regression, state must
be assigned as an object, even though one would think it's automagically
initialized to an object. Oh well!
AtlasKit is not fully compatible with React 16. One problem
is PropTypes will not be defined on the React object. So,
add the prop-types shim to the popup bundle.
virtuacoplenny
Saúl Ibarra Corretgé
Lyubo Marinov
Bettenbuk Zoltan
hristoterezov
paweldomas
damencho
bbaldino
Saúl Ibarra Corretgé
Daniel Ornelas
Guus der Kinderen
Louis Chen
Ryan Peck
George Politis
Boris Grozev
Emil Ivov
yanas