It's actively blocked in code, but I think that's an oversight -
probably leftover from an initial iteration of the feature.
It should be useful in mobile endpoints and it's also supposed to work
seamlessly due to how the feature is implemented.
Lift the mobile block and expose "camera as content" in the presenter's
actions dropdown.
The original BBBVideoStream termination handlers are being overwritten
by screen sharing's service when "Present camera" is started, which
causes the stream not to be dereferenced in the VIDEO_STREAM_STORAGE
map when the camera presentation stops. This breaks subsequent
camera/present camera attempts for the affected deviceId.
The second issue with is that Chrome isn't assigning the
termination handlers for the screen sharing subsystem - which causes
device/permission ejections to be silent.
This extends screen sharing's trackStreamTermination routine to preserve
whatever previous termination handlers were assigned if the stream was
provided beforehand by an external caller - which should fix both of the
aforementioned issues.
This commit removes the wake lock activation toast along with the
enable/disable buttons, implementing the wake lock implicit activation
behavior. The wake lock feature is implicitly activated if the
`defaultSettings.application.wakeLock` in the `settings.yml` file is set
true. For mobile devices that do not support the API or fail when
requesting a wake lock, toasts are raised explaining that calls will be
dropped when the screen turns off.
In cases where `defaultSettings.application.wakeLock` is set false, users
can enable the wake lock manually through the settings menu.
* prevent duplication of presentation menu dropdown when visible
* move presentation options dropdown to the left (out of tldraw UI)
* adjust style menu UI in RTL
* prevent duplication of presentation menu dropdown when visible
* move presentation options dropdown to the left (out of tldraw UI)
* adjust style menu UI in RTL
