These events all happen during a meeting. They tend to be emitted as responses to either what a participant does in a meeting (like sending a message), or updates to the meeting itself (e.g. a live stream starts).
joining-meeting event in the
join() sequence (or as the last step of the
load() sequence, if you invoke that method directly).
Emitted when a participant's camera starts during call loading. This can happen as part of the standard onboarding flow, or when explicitly calling
startCamera() for more granular control.
The details below only apply to
daily-js versions 0.31.0 and up. For all older
versions, look to the
errorMsg field for information of the underlying error.
Also note that
errorMsg is still included and remains unchanged in the
"camera-error" event payload for backwards compatibility, but should be
considered deprecated as of 0.31.0.
Emitted when a camera error occurs. Details can be found in the
included in the event payload. This object will always include
type categorizes the error into a general subset of issues (e.g. permissions
vs missing device).
msg is a human-readable message describing the specific
error. Some types include extra information about the error.
The supported types are:
"not-found": camera and/or mic are not detected. Check the
missingDevicesfield for which devices were not found.
"cam-in-use"/"mic-in-use"/"cam-mic-in-use": on Windows, the camera (and sometimes mic) cannot be accessed in multiple applications at once. When a device is inaccessible for this reason, we emit one of these error types depending on which devices are inaccessible.
"permissions": the user has blocked access to the camera and/or mic, or the browser itself has not been granted permissions. Check the
blockedByfield to know whether it is due to
getUserMedia()was provided with either invalid constraints or empty constraints. Check the
reasonfield to know which one was the case.
"undefined-mediadevices": This indicates that
window.navigator.mediaDevicesis undefined and a
getUserMedia()call is not possible. This most commonly is a result of accessing the call via a non-secure
"unknown": While we have done our best to handle and normalize all possible errors across browsers and common device issues, we were unable to categorize this error. All unknown errors will be reported as this type. The original error thrown by
getUserMedia()will be included in the
This event could be used to monitor whether a call is fully loaded in the console, or to hide certain displays while the participant is joining the meeting, among other things.
Emitted once the local participant has joined the call. At this point, the call is considered connected.
joined-meeting event object returns the
"action" type and information about the local participant who joined, like their
"screen" state, and any media stream tracks.
participants list will only ever include the local participant. This is
because the server sends participant information in batches of 50 after this
initial joined event occurs. To get a participant count at join time, use the
method. To get detailed participant information, listen for the
sent in conjunction with the batched updates.
Fires once the local participant has left the call. From the local user's perspective, this means the call has disconnected.
You could watch for this event to change the UI once a user has left a call, for example, changing a button that read "Leave call" to display "Join call" (we do something similar in our Daily Prebuilt demo).
A meeting session is a set of one or more people in a room together during a specific time window (learn more about meeting sessions.
'meeting-session-updated fires when the meeting session changes. One meeting session ends and another begins, for example, when you've been sitting alone in a room for 10 minutes.
Fires when the call iframe enters browser fullscreen mode, usually when a local user clicks a button that calls our
You might listen to this event to modify other parts of the UI accordingly, e.g. shrinking or hiding a participants list temporarily.
When a user closes fullscreen, the
exited-fullscreen event fires. This can be useful to listen for if there are UI elements you'd like to reappear once a user returns to their default view.
active-speaker-change event fires when the person currently talking has changed. While Active Speaker is only available for calls making use of Daily Prebuilt, you could still listen for
active-speaker-change to build your own custom UI.
One use case would be to listen for it to alter the UI for the person currently speaking, or to temporarily mute other microphones.
Daily determines the active speaker based on whose audio input is currently the loudest. The active speaker is displayed prominently, while everyone else is displayed smaller. Active speaker mode only applies to the local participant, so changing the mode only changes the view locally.
peerId value is the same as the
session_id in the participants object.
The Daily Active Speaker mode only exists by default for calls using Daily Prebuilt. When Active Speaker mode is enabled, the participant that is currently speaking is displayed prominently, while others are displayed smaller (check out our blog post for more).
active-speaker-mode-change event fires when Active Speaker mode is toggled either through a button in the default UI or programmatically using
If you're using the Daily Prebuilt, then you can listen for this event to see if Active Speaker mode has been properly set.
However, if you've built your own custom UI to emulate Active Speaker, the
active-speaker-mode-change will not fire. Its related methods
setActiveSpeakerMode() will have no effect.
This event fires when
accessState() has changed in some way—either the current access has changed (
accessState().access) or an access request has been made or has been resolved (
accessState()for object format
error event fires when an an unrecoverable call error, like a total disconnection, occurs.
errorMsg property will contain a string with additional information. It can be useful to listen for and log
error events for debugging and troubleshooting, for example.
If a call is in progress when the error is thrown, a
left-meeting event should be emitted immediately after the error event.
Emitted when a theme is applied, via setTheme(), for example. The event's object looks like:
Fires when media receive settings have changed (see
updateReceiveSettings() for details). This occurs once upon
join—at which point the
base receive settings come in—and once each time receive settings are changed via a call to
Fires when a local participant hides or shows their own video element (or when the
setShowLocalVideo() method is called).
Emitted every time the input settings object changes (see
updateInputSettings() for details). Includes all input settings, even those that have not changed.
Fires if and when an error occurs while applying input settings changes.
Emits if there is an error when a participant begins a screen share.
This error can occur for two reasons, described in the
- The user has not permitted the browser to access screen sharing. The
"Error starting ScreenShare: blocked-by-browser".
- The user's OS has been configured to block screen sharing. The
"Error starting ScreenShare: blocked-by-os".
Emits if there is an error during a live stream, such as when a user attempts to remove all live streams with
Fires when a local participant clicks a custom tray button.
You might listen to this event and use the
button_id from the payload to call your custom button behavior.