Found in

• Firefox 107.0b9

Affected versions

• Firefox 107.0b9
• Firefox 108.0a1

Tested platforms

• Affected platforms: Windows 7, macOS 13, Ubuntu 22.04
• Unaffected platforms:

Steps to reproduce

1. Launch Firefox
2. Access this audio sample
3. Double click over the play/pause button or over the audio player time

Expected result

• The fullscreen mode is not launched

Actual result

• Firefox will enter in fullscreen mode

Regression range

• Will see for a regression
• This was previously fixed in Bug 1776222, and now seems to be back

Additional notes

• The issue can be seen in the attachment

Possible side effect of fixing bug 1793889 which was intended only to re-enable double-clicking <video> elements playing only audio.

Bernard, do you know what's happening here?

The audio file is being presented in a video tag. Since bug 1793889 reintroduces the double click full-screen feature on audio only video tags, that feature is also present here. One possible fix would be to present audio files in audio tags. Unfortunately, I could not figure out how that works. Is there someone who has more context on how the page that displays audio files is generated?

(In reply to Bernard Igiri from comment #3)

The audio file is being presented in a video tag. Since bug 1793889 reintroduces the double click full-screen feature on audio only video tags, that feature is also present here. One possible fix would be to present audio files in audio tags. Unfortunately, I could not figure out how that works. Is there someone who has more context on how the page that displays audio files is generated?

https://searchfox.org/mozilla-central/rev/3c194fa1d6f339036d2ec9516bd310c6ad612859/dom/html/VideoDocument.cpp#108-109 . DOM and media folks would be the best people to ask if you needed more context - looks like a lot of the people who worked on that bit of code have since left Mozilla.

I'm not sure if it's actually possible to deduce, when creating the video element, whether the file is an audio file - so I'm not sure if what you propose is viable. The DOM/media folks should be able to help answer that. Alternatives include wontfixing this, or figuring out why in bug 1793889 we didn't restrict fullscreen behaviour to audio-only video elements with poster (as the video element generated here won't have poster), or to check for a video track in the custom element code. So it's probably worth thinking about what the right behaviour is for users and then think about how to achieve that.

Set release status flags based on info from the regressing bug 1793889

Set release status flags based on info from the regressing bug 1793889

Needs feeedback from dom media controls folks -> looks like defined behavior.

Hi Bernard, can you summarize in a comment why you closed this out as wontfix? Was there already a discussion with the media folks per comment #7, perhaps?

(In reply to :Gijs (he/him) from comment #8)

Hi Bernard, can you summarize in a comment why you closed this out as wontfix? Was there already a discussion with the media folks per comment #7, perhaps?

I did not talk to the media folks, but I did see the update:

No longer blocks: media-triage
Flags: needinfo?(bigiri@mozilla.com)

So my assumption is that the media folks agreed with comment #7.

(In reply to Bernard Igiri from comment #9)

(In reply to :Gijs (he/him) from comment #8)

Hi Bernard, can you summarize in a comment why you closed this out as wontfix? Was there already a discussion with the media folks per comment #7, perhaps?

I did not talk to the media folks, but I did see the update:

No longer blocks: media-triage
Flags: needinfo?(bigiri@mozilla.com)

So my assumption is that the media folks agreed with comment #7.

Yep, we felt media player folks should make the call, especially since they were making changes here recently.