Moving to OggHandler, assigning to Michael Dale as part of video UI rework...

smorpg wrote:

I have found the source of this problem as well as a simple workaround:

The reason this happens is because the <audio> tag specification does not support resizing, while the <video> tag specification does. As Firefox, Chrome and Opera all follow this specification, neither of the three support <audio> resizing, however <video> resizing works fine.

Therefore, the simply workaround is to simple use <video> instead of <audio>, since they both use the exact same backend to handle content.

In /extensions/OggHandler/oggPlayer.js

Change line 558 from
var tagName = params.isVideo ? 'video' : 'audio';
to
var tagName = 'video';

It's a workaround, but it helps. I have tested this on my private mediawiki and now Firefox is completely fixed, Chrome resizes correctly but handles the player itself weirdly (but I assume this is a fault on the side of Chrome), however Opera still acts the way it did before the change (but this is a fault on the side of Opera now, not the specifications).

svenmanguard wrote:

Great news. Let's do this then! Sound implementation on Wikipedia leaves much
to be desired, but this is near the top of my list of issues with it. Fixing it
would be just wonderful.

mdale wrote:

TimedMediaHandler has an html5 audio ui which gets around the native size issues of the browsers native audio players.

(In reply to comment #4)

TimedMediaHandler has an html5 audio ui which gets around the native size
issues of the browsers native audio players.

Does that mean this is fixed, then?

mdale wrote:

It should be marked as wontfix "bug" with OggHandler since its big bug to build an html player and that "big bug" is addressed by the feature set of the TimedMediaHandler extension.

TimedMediaHandler updates the video tag output with an HTML player that is more adaptive to custom sizes.