Change the previous loading spinner to the new loading dots, ensuring
a bit more UI consistency.
Add the "unhealthy stream" filter to make the dots a little more visible and
remove the loading spinner.
Scenario: presenter`s client could crash when the presenter changed while they were sharing their screen
That is due to a race condition on the stop procedure in the bridge: two stops can be triggered (one from the server-side websocket tear off and another from the client itself detecting the presenter change)
That could create a scenario where the broker was cleaned in one stop procedure after the second had checked its availability, causing an attribute access of a null member
Generate a external_videos.json file at the recordings with an array of
played external videos url and timestamp.
This file will be published along with the other presentation format files
and can be used to display at the playback.
When mic is locked, user is not able to talk so it doesn't make sense
to alert the user about unmuting (mute button is also disabled when mic
is locked).
Closes#12048
This complements #12694, which was initially made using an
existent font (which may vary it's size depending on OS/browser)
Added a new specific icon for the device icon selector
Thanks to @ramonlsouza who found this problem
Firefox doesnt fire the ended evt/onended callback for live video mediastreamtracks. That caused the stream storage to not run the cleanup procedure in some scenarios
Manually emit the ended event which works with the onended callback when a track is stopped
> In an ideal world with infinite resources, there would be no need for
> this app.
>
> But in any successful software project, there's always more work to do
> than people to do it. As more and more work piles up, it becomes
> paralyzing. Just making decisions about what work should and shouldn't
> get done can exhaust all available resources. In the experience of the
> maintainers of this app—and the hundreds of other projects and
> organizations that use it—focusing on issues that are actively affecting
> humans is an effective method for prioritizing work.
>
> To some, a robot trying to close stale issues may seem inhospitable or
> offensive to contributors. But the alternative is to disrespect them by
> setting false expectations and implicitly ignoring their work. This app
> makes it explicit: if work is not progressing, then it's stale. A
> comment is all it takes to keep the conversation alive.
https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea
This file add the configuration needed for stale issues and pull requests
to be automatically closed. Defined as follows:
- issues and pull requests with no activity for 270 days will be marked as "status: stale";
- after that, there will be a period of 90 days for the issue or pull request to be claimed, otherwise will be closed.
The bot will never interact/close with issues and pull requests marked as:
- status: vetify
- status: accepted
- target: security
- type: discussion
For this setup to be effective, add https://probot.github.io/apps/stale/
to BigBlueButton repository.
