479936 - video with width= or height= does not scale container (although it scales the video itself)

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P2)

Description

[Christopher Blizzard (:blizzard)]

This is easy to reproduce.  Do something like:

<video src="http://people.mozilla.org/~blizzard/screencasts/screencast-video-2009-02-23.ogv" width="300" controls="true">

in your HTML.  Note that it will scale the video down from its original size but the height and width of the box that contains the video will be the full height of the video.  Seems like some maths are missing somewhere.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: testcase (not)

I don't see this bug on trunk as you describe it.

I think this testcase covers what you're describing. It seems to work fine; the green border-box is the intrinsic height of the video and 300px wide.

Comment 2

[Christopher Blizzard (:blizzard)]

Attachment: video sizing bug on trunk + 1.9.1 branch

I caught it on both the 1.9.1 branch and trunk - screenshot attached.  I was able to reproduce on trunk by clearing the cache and reloading.  It doesn't happen every time but it does happen.  (And when I was using it on my blog it _did_ happen every time which is why I noticed it.)

Comment 3

[Christopher Blizzard (:blizzard)]

Adding bz + dbaron for some reflow/resizing love.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So nsVideoFrame::GetIntrinsicSize uses the video size but overrides the width or height based on the attributes set, if any.  This gives the behavior roc describes in comment 1 and shown in the screenshots in comment 2.  Neither matches the description in comment 0; in particular the width used is the one specified by the attribute, not the height of the video as comment 0 says.

The HTML5 spec doesn't actually say what the width and height attributes on <video> do, so I have no idea what the right behavior here is.  The current behavior _does_ seem a bit odd to me.

If we want them to act more like equivalent attributes on <img>, then we need to map the width and height attributes into style and not have them affect the intrinsic size.  But again, that's a spec question.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, sorry.  The spec has this "The video element supports dimension attributes." thing very well hidden in the text.  Of course the spec doesn't define what those do.

Comment 6

[Christopher Blizzard (:blizzard)]

Hmm, interesting.  The principal-of-least-surprise would expect it to do exactly what an <img> does when you specify only a width or only a height.  It's the easy way to fit-to-width for a lot of pages.   Who are the right spec people?  (I can't imagine that anyone would want anything else, frankly.)

Comment 7

[Boris Zbarsky [:bzbarsky]]

I've posted to public-html and whatwg requesting clarification, but it seems to me that the intent of the spec is in fact that these attributes behave on <video> as they do on <img>.

Comment 8

[Boris Zbarsky [:bzbarsky]]

And to be more precise, it just happens to not define what they do on <img> either.

Comment 9

[Boris Zbarsky [:bzbarsky]]

An extra fun question.  Should hspace/vspace/border be supported on <video>? They're not in the HTML5 spec at all, for anything...

I'd guess "no".

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so, perhaps

This still needs tests; I'd appreciate it if someone more familiar with when it's ok to take a snapshot would put those together...

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 364144 [details] [diff] [review]
Like so, perhaps

oops

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: with tests

Comment 13

[Matthew Gregan [:kinetik]]

Pushed 98f8aef2dce4.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/11e11905e4ba