Requested locally in that case here.

This is a problem with a local gadget (https://commons.wikimedia.org/wiki/MediaWiki:Gadget-Stockphoto.js#L-427), not the MediaWiki software, so never belonged on Phabricator.

Phabricator is not just for the MediaWiki software. Several gadgets track issues on Phabricator.

@Sdkb I’m trying out the embed code at https://tmp.lucaswerkmeister.de/T404934.html and it’s not clear to me if it’s useful for audio files at all… am I supposed to see something more than just an “info” button?

it's overflowing the controls, because it's not wide enough to show all of them. There's some sort of logic in core to show it on smaller sizes (by applying different classes), but I think because your canvas uses a different fontsize, those classes don't work here. But if you use a minimum of 350px, then it shows all the controls.

To make sizing etc more advanced (in the way that YouTube does it), you actually need to program all kinds of steps into the iframe providing code, to dynamically measure the frame you are being embedded into, set fontsizes etc.. its a lot of work, and the foundation is not willing to invest into it as far as I know.

Regardless, the functionality provided by the Gadget is not officially supported, it's only there because no one want to take the effort to remove that Gadget and deal with the community (15 year status quo).

While 20px is too small (gadget problem, should always be 30px), it seems that the content is actually 40px height, which is too high...

https://gerrit.wikimedia.org/g/mediawiki/extensions/TimedMediaHandler/+/8b04a774643041273a5120048e19e5bcb18471d7/resources/ext.tmh.player.inline.styles.less#17

This rem is probably an issue. &.vjs-fill, is targeting the dialog mode, but the embed player mode uses vjs-fill as well. It thus sets the size of the embed player to be document relative, while, as stated, it should just be 10px to remain predictable.
I remember when that patch was merged to turn it into codex tokens, I was already suspicious that it might cause a problem.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/1118041
T385857#10535214

In T404934#11197217, @TheDJ wrote:

it's overflowing the controls, because it's not wide enough to show all of them. There's some sort of logic in core to show it on smaller sizes (by applying different classes), but I think because your canvas uses a different fontsize, those classes don't work here. But if you use a minimum of 350px, then it shows all the controls.

I see, thanks. Should we change the gadget to 350px then? (I think that would be in line 553-4.)

Phabricator is not just for the MediaWiki software. Several gadgets track issues on Phabricator.

Sure, some specific gadgets track issues here. But the Commons stockphoto gadget doesn't seem to be one of them.

That gadget does not have an issue tracker in Wikimedia Phabricator and Phabricator is not a catch-all place for random stuff.
If Commons folks actually want to track random Commons things here and also work at them, they could do so though, thus adding the Commons project tag.

In practice they don't. Commons is a bot-created wasteland where tasks tend to stall forever, and Local-Wiki-Template-And-Gadget-Issues is not much better. I'm not going to status war here, but I don't see why this needs to be on Phabricator when the edit request process on Commons is also tracking it.

And both of those tickets should also have been closed as invalid.

I agree with all of that.

Following up on the confusing scope of the Local-Wiki-Template-And-Gadget-Issues project at T406770