If it helps, I’m testing on latest stable (2.0.7439-1) and observed that:
“Start recording” option not visible if enableLocalRecording: true and fileRecordingsEnabled: false
Option shows up once I set fileRecordingsEnabled: true, albeit with the unwanted option.
sounds like messy business.
In a pinch, I’d settle for the “Leave Meeting” button being replaced by a “Stop Recording” while local recording is in progress, but I’m aware that’s more a cheap workaround than a proper solution.
This also brushes on another very minor usability issue – up until I discovered that the “Stop sharing” button provided by the browser also stops recording, all my recordings end with a view of me hunting for the “Stop recording” option in menu, with the final frame always the confirmation modal.
Perhaps a more prominent button to stop recording, or to auto stop on leave, could help with a more natural stop to recordings
Do we need the confirmation modal? It is inconsistent with stopping using the the “Stop Sharing” browser action, which will terminate the recording without confirmation.
For #2, the notification we now get which reminds users to stop recording before leaving helps a little, but I have a bad feeling that is insufficient and users are still going to forget after a long meeting.
The only alternative I can think is a lot messier – have users only use via IFrame, use toolbarButtonClicked event and window beforeunload events to intercept meeting leave and tab close intent, then somehow check if local recording is running and handle accordingly.
Is either approach viable? Happy to attempt a PR with some guidance if it is not too complicated
Any chance we could get LocalRecordingManager.isRecordingLocally() (or something to that effect) exposed to ExternalAPI? Or any other way to programmatically infer using IFrame API will do. I initially assumed we could infer local recording state from recordingStatusChanged event, but that does not appear to be the case.
P.S. I understand it is too soon to design a solution for the quit-without-stop-recording case, but I am compelled to explore short-term options in case a sudden need arise. Intercepting hangup from outside IFrame seems like the easiest to achieve and maintain.
OK, I managed to infer local recording state based on local.localRecording from features/base/participants state (via api.getIFrame()). This “works”, alas accessing state that way is of course brittle and could break at any time.
But at least I have a proof of concept working. Hopefully I don’t need it, but I sleep better at night knowing it is there
For the record, this was what I did:
Set buttonsWithNotifyClick: ['hangup'] in config.js so leave button does not actually leave but only triggers event.
Caveat: this breaks UX if someone goes direct to page and not via IFrame.
Using IFrame API, listen to toolbarButtonClicked event.
if key is “hangup” and local recording running, alert user that recording must be stopped first.
otherwise, call executeCommand('hangup') to actually leave.
So with local recording state now inferable from recordingStatusChanged, it is now pretty straight-forward to intercept hangup and warn users if recording is still active.
The only missing piece here is a nice way to display warnings to users within the context of the app. I’ve implement this by manually building the SHOW_NOTIFICATION action payload and dispatching via APP.store.dispatch but this could get brittle over time.
Would you consider a PR to add either api.showNotification(...) or api.executeCommand("showNotification", ...) to IFrame API?
I’m looking to intercept and warn users when they attempt to leave the conference while recording is still active.
I do see the sticky notification at the start of the recording, but users are bound to forget after a long meeting and will inadvertently click Leave before stopping, then complain later when they cannot recover the recording