User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

1. set media.autoplay.blocking_policy to 2 in about:config
2. go to https://meet.jit.si and start a room there
3. allow audio and video in the firefox permission popup
4. see a static frame from the camera in the video preview window instead of the continuous camera video feed

To fix this, currently one has to continue with:
5. disable the video with the controls provided by the website
6. reenable the video with said controls
7. get a functioning video feed as it should be

Tested on FF 95 as well as on 97/nightly, tested on Wayland (sway 1.6.1) as well as on XWayland (i.e. MOZ_ENABLE_WAYLAND=1 as well as =0), problem appears on both backends.

Actual results:

When using a WebRTC video conferencing solution, such as https://meet.jit.si (just exemplarily, others exhibit the same issue), only the initial camera frame is shown as a static image in the video feed, not the video.
This is fixable by disabling video and reenabling it via the website-provided buttons to do so. After that, video is shown as video.

Expected results:

Camera feed should show as video instead of static image right away, regardless of the toggle state of the video-button in the web solution.

(Or, if freezing the video is actually the intended behavior of media.autoplay.blocking_policy == 2, it should do so consistently, by either not show any frame or by continuing to not show video in the first place, however, in that case, an alternative solution for stopping autoplay is needed as this is currently to my knowledge and experiments the only solution to reliably block autoplay at least on Youtube, possibly more websites).

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

I can repro (I also need to set media.autoplay.default = 5). My understanding of media.autoplay.blocking_policy = 2 is that you need to explicitly interact with the media element in order to allow it to play, and that's why you need to do to the extra steps to enable playback. Alastor, does that sound right to you? If so, is there anything to be done here?

I also need to set media.autoplay.default = 5

I can confirm that this is set for me as well, apparently I didn't verify it with different levels of media.autoplay.default, sorry for the inconvenience.

and that's why you need to do to the extra steps to enable playback

That sounds plausible, in that case would it be considered a bug that the very first frame of the video is visible? Because it looks suspiciously like "webcam started to play, then froze", in case the "play when interacted with the element" mechanic is at play, shouldn't there be not even the first frame of the video visible? This is what gave me a hard time finding the culprit (until I started to bisect options), but it might also be a consequence of me misinterpreting the setting for the blocking policy.

(In reply to j.grs-mozillabugs from comment #3)

That sounds plausible, in that case would it be considered a bug that the very first frame of the video is visible? Because it looks suspiciously like "webcam started to play, then froze", in case the "play when interacted with the element" mechanic is at play, shouldn't there be not even the first frame of the video visible? This is what gave me a hard time finding the culprit (until I started to bisect options), but it might also be a consequence of me misinterpreting the setting for the blocking policy.

If you haven't yet seen this page, it has a great discussion on the different settings and helps provide context for some of the stuff I discuss below.

Showing the first frame of the video is our normal behaviour for blocking autoplay, though I agree it is unintuitive here to see your camera start and then not play. In this case that's down to site design interacting with block autoplay.

Part of the reason for our default behaviour (pref media.autoplay.blocking_policy=0) is that is avoids issues like this. While some of the other autoplay blocking strategies are effective, they can create cases that are unintuitive for users and where the browser cannot determine what the right thing to do is. E.g. in this case, the video of your camera is seen to the browser to just be a video that you haven't interacted with. If this were an ad, it'd be great if we didn't let it start playing, but because it's your camera feed, it's bothersome that it doesn't play.

You could switch your pref setting here, alternatively, you could set an exemption for the site.

Thinking about this, I don't know if there's more we can do here, so I'll resolve this. Happy to answer more queries if you have them.

Alastor, please correct me if I've gone off base, and also re-open if there's more we can do here.

I wasn't aware of that wiki page, that's a good resource, thanks!

Yes, since my last comment I have also thought about the issue and you just confirmed my suspicion, it's unclear from a browser point of view where that video comes from, in this particular instance it just happens to be the one from the camera.

I will see if I'll manage with media.autoplay.default < 5, as apparently when I experimented I didn't try blocking_policy=2 as well as default<5, but it seems this does hinder youtube from autoplaying, which was the original goal (then again, knowing the inner workings behind the problem now, I might also simply adjust to double tapping the video disable button).

Thank you very much for the insight, and thanks for your good work! :)

What Bryce said are all correct, but it seems that we can do better for this. For other blocking policies, we would allow pages to autoplay once pages grant a permission for camera/micphone/screen. But we didn't apply this to click-to-play policy (media.autoplay.blocking_policy = 2), it seems to me that we should do the same thing for that policy in order to let users see videos for web conferencing.

In addition, videos for web conferencing are different from usual media playback, and users usually don't really need to click on those videos because there is no an explict control interface to play/pause a real-time conferencing videos.

I also thought if there is the option of adding an overlay akin to a play button to those elements, that would make the "problem" effectively obvious. On the other hand, allowing media playback on sites that have gotten permission for audio/video also sounds pretty reasonable. I just now realize that the videos within a call did always play on their own, although I didn't explicitly interacted with them, I think?

I just realized something (on FF 96.0.2, not sure how that was in older versions, but might have been the same): while I get a permissions-badge on the left side of the URL bar on the pages that would play videos to me, where I could adjust blocking policies for this website with regards to audio and video, I did not get that badge on youtube, where I would have expected to get it (and youtube automatically starts playing). That being said, while I got the permissions-badge in jitsi, it only included Camera and Microphone, but not the option to Block autoplay for video and audio. This behavior does make sense for jitsi, but purely from a non-technical user perspective, it doesn't on youtube.

My default setting currently is to automatically block audio and video via the preferences, so media.autoplay.default == 5, but media.autoplay.blocking_policy == 0 currently.

Not sure if this is of any help, but I thought I'd share that observation just in case.

I was about to file a bug about "Prompt for per-site permissions exception to enable autoplay when microphone and/or webcam is turned on in WebRTC", because while I don't expect videoconferencing systems to work automagically with my media.autoplay.blocking_policy == 1 and media.autoplay.default == 5 configuration (set this way to avoid autoplaying BS on news sites), remembering to create an exception for every video conferencing system/website out there is problematic, and even if I do remember to do so, the road to creating an exception is arcane and tedious. You have to do these steps as a user:

1. Click the padlock icon in the address bar / awesomebar
2. Click "Connection secure"
3. Click "More information"
4. Finally get access to the "Page Info" dialog (bug #1725369)... then click the "Permissions" tab
5. Under "Autoplay", uncheck "Use Default" and then force-allow audio and video for that website.

It's almost impossible for someone who doesn't know and remember the special incantations to get to that point.

My suggestion then would be to have Firefox's standard permissions exception prompt to appear when needed to allow adding a per-site exception to autoplay when the microphone and/or webcam permission has been granted (whether temporarily or permanently) for that site.

Is this the right bug report here to be making this suggestion, or should I file a new standalone bug report?