1683979 - audio element not rendered correctly

Status: RESOLVED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[exekutive]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

visit a web page containing embedded audio
(<audio src="......)
a width is not explicitly coded

example:
https://carkiller.com/scottykilmer/qa/jeep-wrangler/#post-32602

Actual results:

unable to play the audio. Controls not visible. Only a small rectangle.

Expected results:

the embedded audio should be presented in such a way that it can be used ie. render the controls. The correct behaviour can be seen in Chrome and Safari browsers.

https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-12-17-14-27-16-8240a6.png
https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-12-17-14-27-12-60190c.png
https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-12-17-14-27-07-554838.png

Comment 1

[Negritas Sergiu, Desktop QA]

Hello I have managed to reproduce the issue using the STR provided in the description with Firefox 84.0, 85.0b4 and 86.0a1(12-28-2020) on Windows 10, Ubuntu 20 and on macOS 10.15.7.
I will add a component to this issue so one of our developers could look more into it. If it's not the right component please feel free to change it to an appropriate one.

Comment 2

[Alice0775 White]

Attachment: reduced.html

Comment 3

[Alastor Wu [:alwu]]

Audio works well on the page if you play that audio element directly, so this seems to me a CSS problem.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

You can fix this removing the audio { max-width: 99% } rule, fwiw.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1683979 - Audio min / pref isize should not depend the controls. r=dholbert,#layout

Otherwise the adjustments that the video controls do in response to
size changes affect the size itself, which can cause cyclic layout.

Comment 6

[Daniel Holbert [:dholbert]]

Does this help with the testcase in bug 1619247, out of curiosity?

Comment 7

[Daniel Holbert [:dholbert]]

A bit of a tangent:

I noticed that percent sizes seem to force the audio element to have a 0-size in Chrome, for some reason (if it's in an intrinsically-sized container). At first I thought that might have something to do with the "compressible" concept, in the spirit of bug 1585485 , but it's not behaving quite that way (in either Chrome or in Firefox) so I don't think either browser is applying quite the same logic as they do for "compressible" stuff.

Here are two testcases, which I think should behave roughly the same as each other (aside from the fact that input and audio have different intrinsic sizes and hence will prop up their container to a somewhat different extent):
audio: https://jsfiddle.net/dholbert/n63qyfb5/
input: https://jsfiddle.net/dholbert/kz7u5yf3/

Firefox Nightly and Chrome agree with each other on the input testcase, but they don't agree on the audio testcase, particularly its second line, "Percent-width, intrinsically sized container" -- and neither browser's behavior on that line agrees with the analogous line in the <input> testcase.

It feels like we should be internally consistent on that second line -- i.e. that audio elements should behave the same way as input elements in these scenarios. They feel similarly-"compressible" to <input> textfields, in that they have a relatively large min-content size, which is the same as their max-content size, and they are also OK being rendered to sizes smaller than that while handling/avoiding overflowing content on their own. So intuitively, I might expect them to behave the same, sizing-wise, under the conditions relevant to "compressible"-ness.

Anyway, that's outside the scope of this bug; but I am curious if the patch changes our behavior on this audio jsfiddle testcase.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

Does this help with the testcase in bug 1619247, out of curiosity?

This fixes bug 1619247 too, looks like.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

(In reply to Daniel Holbert [:dholbert] from comment #7)

Anyway, that's outside the scope of this bug; but I am curious if the patch changes our behavior on this audio jsfiddle testcase.

It doesn't, afaict.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b6ffa3734156
Audio min / pref isize should not depend the controls. r=dholbert

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27052 for changes under testing/web-platform/tests

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/b6ffa3734156

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot