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

Steps to reproduce:

1. Create an <audio> element with controls="controls" and a style of max-width: 100%.
2. Place that element inside a <div> which has overflow: hidden and a CSS transition on its width going from 0 to {something more than large enough for the audio element to fit inside}.
3. Trigger the CSS transition to expand the width of the containing <div>.

Actual results:

The <audio> element does not fully expand to its "correct" size.

Expected results:

I expect the <audio> element to be the same size as it would be if the surrounding <div> had started at the final size (rather than transitioning to that size from 0).

HTML file with HTML/CSS to reproduce the issue is attached.

For posterity, (and in case it doesn't reproduce for others) here's a video of the bug being reproduced with that file: https://www.flickr.com/gp/adamalton/50Y425

On my end, on Windows 10, all the latest versions of the main channels reproduce the following behavior: The audio controls below the "With transition on size of wrapper" subtitle is properly displayed on page load (that is displayed like the one above is displayed), but after clicking the "Toggle size of surrounding <div>" button 2 times (to close and reopen the div), the audio controls are no longer displayed.

I attempted performing a regression and I can provide this, before mozregression told me that there is not enough data to bisect.
2020-03-06T16:04:20: INFO : Narrowed nightly regression window from [2016-11-18, 2016-11-20] (2 days) to [2016-11-18, 2016-11-19] (1 days) (~0 steps left)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

The priority flag is not set for this bug.
:bgrins, could you have a look please?

For more information, please visit auto_nag documentation.

This seems like a layout issue

Here's a somewhat reduced testcase, simplified to remove the transition and the percent max-width, and instead just setting the max-width on the audio element directly.

If you e.g. click "90px" and then "Unset", the audio element gets "stuck" in its 90px-sized rendering. Similarly, if you click 60px and then 90px, it stays stuck at the 60px rendering (it doesn't grow to 90px). This is true of all of the width options here (for me at least) -- they're all "sticky" -- except for 10px (which seems to be skinny enough to be an "unstable" point where we'll allow ourselves to reset if we jump from it to a larger size).

This seems to be a regression from the audio-widget-redesign in bug 1271765 (which landed on mozilla-central around 2016-11-19) -- either that bug or an associated bug. Nightlies from that month seem to crash for me (the ones I tested at least), so I can't test a "tight" regression window, but I was able to get these nightlies to run:

• 2016-10-01: good
• 2016-12-01: bad

(This range includes bug 1271765 & is a tight enough range to make me confident in calling this a regression from that bug, given the scope of its redesign and the number of other similar issues that were caught in review and/or as other regressions in the time after it landed. e.g. this is kind of similar to bug 1339269 which was also a regression from that change)

So: this is an ancient-enough regression that there's no sense in tracking/maintaining per-release "affected" flags, so I'll go ahead and clear those.

I recall this audio/video control-sizing code being pretty troublesome -- there's some hacky interplay where the controls pretend they have a particular intrinsic size (e.g. width of buttons + scrubber-track) but then run some JS to hide pieces of itself (e.g. hiding the scrubber-track) to accomodate smaller specified sizes. It looks like that size-adjusting is triggered by actual changes in the controls' size (via the internal "resizevideocontrols" event[1], I think), which then runs some JS to resize/hide internal components. If we simply change the max-width, then that doesn't directly change the controls' size, so it doesn't trigger the JS that does all the resizing/hiding/showing magic. So we end up in a kind of chicken-and-egg scenario where we don't think we need to resize because none of the components have changed their sizes, and none of the components realize that they might be able to change their sizes because we never fired the "resizevideocontrols" event, because we never resized.

The code in question lives in https://searchfox.org/mozilla-central/source/toolkit/content/widgets/videocontrols.js and https://searchfox.org/mozilla-central/source/layout/generic/nsVideoFrame.cpp , BTW.

[1] (yes, "resize video controls" -- this bug is about audio controls, but the video/audio controls implementation is shared. And video controls are likely similarly affected.)

Thanks for the bug report, Adam! Out of curiosity, do you know of any "real" web content that's broken by this? (e.g. did you happen to run into this while designing a site & have to work around it?)

(Ah, and I see comment 1 has a tighter regression range than I was able to get, and confirms that this regressed on/around 2016-11-19, which adds confidence in this being caused by bug 1271765.)

Reading comment #7, is this actually solvable in the audio/video controls without cooperation from layout, other than via some kind of polling mechanism where we try to check (unsure how) if we have "more space" than before?

(clearing priority because this bug moved components since it was set)

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

Reading comment #7, is this actually solvable in the audio/video controls without cooperation from layout, other than via some kind of polling mechanism where we try to check (unsure how) if we have "more space" than before?

I don't think it's solvable in a purely-JS way. I think this needs some hackery in nsVideoFrame.cpp to be fixed.

Basically, the special scenario here is having audio/video controls...

• which are at least partially content-sized (e.g. width:auto or maybe even min-width:auto in flex/grid containers, not sure),
  ...and:
• which had constraints that have been partially relaxed (e.g. having had a specified width that was later removed, or having max-width increased or removed)

This results in a scenario where we have some components that are hidden which are no longer contributing any desired size to us which never get us to realize that we have space for them.

We may have to just add logic in nsVideoFrame.cpp to detect such scenarios, and fire a different event which causes the JS to try adding all the components back, or something. (Or we could reimplement our controls logic in C++ to react to the available-space right away, dynamically, during reflow, but that's probably not something we want to do.)

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

Thanks for the bug report, Adam! Out of curiosity, do you know of any "real" web content that's broken by this? (e.g. did you happen to run into this while designing a site & have to work around it?)

Sorry, I missed the notification about this. Yes, I came across it while building a site which includes a media player which gets shown/hidden in the page. So the surrounding element of the audio player changes in size. I've worked around it, but I do have a real use case which the bug is affecting.

Thanks. Good news, we believe we've fixed this over in bug 1683979 (which is fixed in current Nightly); I verified that the attached testcases are now fixed in Firefox Nightly.

Marking as a duplicate of that now-fixed bug.