938772 - empty <video> tag attempts to load href of <base> tag

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Jon Buckley [:jbuck]]

Attachment: Page with base and video tag

If you have a page with a <base> tag and an empty <video> tag, Firefox will attempt to load the href of the <base> tag into the <video> src.

Chrome 31 and Safari 7 do not attempt to load the <base> tag value in the video element.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

roc: any ideas what's up here?

Comment 2

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

Not off the top of my head.

Comment 3

[Hallvord R. M. Steen [:hallvors]]

Perhaps HTMLMediaElement::MediaLoadListener listens to too much stuff and picks up something related to the BASE tag?

Comment 4

[Hallvord R. M. Steen [:hallvors]]

FWIW, "attempts to load" seems to be somewhat incorrect - I made a test case with a BASE href pointing to a video file, it doesn't get loaded into the <video> element and the error event still fires. So I assume <video> doesn't *actually* try to load the referenced URL, it just gets some logic wrong in the "was something loading/loaded" department?

Comment 5

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

What's happening here is that the video element contains an anonymous <img> element to show the poster image. There is no poster attribute in this case, of course, but we set the poster 'src' attribute to the empty string anyway. The poster <img> then tries to resolve the empty string against the base URI (against the HTML5 spec), and tries to load that. In the attached testcase the load fails and the resulting error event is fired against the video element for some reason. If you change the base href to a valid image URL, the image will actually load as the poster.

Comment 6

[Matthew Gregan [:kinetik]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5)
> In the attached testcase the load fails and the resulting error event is fired
> against the video element for some reason.

That part is bug 516811.

Comment 7

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

Attachment: fix

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8340891 [details] [diff] [review]
fix

Review of attachment 8340891 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/generic/test/mochitest.ini
@@ +78,5 @@
>  [test_bug791616.html]
>  [test_bug831780.html]
>  [test_bug841361.html]
>  [test_bug904810.html]
> +[test_bug938772.html]

You forgot to add the test file to the patch. I'll assume it's sensible. ;)

Comment 9

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

(In reply to Chris Pearce (:cpearce) from comment #8)
> You forgot to add the test file to the patch. I'll assume it's sensible. ;)

Nah, it's actually there :-)

Comment 10

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

Oh wait, no it's not. It's in my patch locally though. Sorry.

Comment 11

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/8b51998bca5b

Comment 12

[Carsten Book [:Tomcat]]

Hi,

sorry had to backout this changes in https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=9b8364f50488 for test failures in mochitest 5 on windows like https://tbpl.mozilla.org/php/getParsedLog.php?id=31430804&tree=Mozilla-Inbound (timeout) and also on Android like https://tbpl.mozilla.org/php/getParsedLog.php?id=31430347&tree=Mozilla-Inbound - ERROR TEST-UNEXPECTED-FAIL | /tests/layout/xul/test/test_bug511075.html | function () {

Comment 13

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

It's possible for the iframe load event to fire before the script adds the load event handler (though I would have expected that to be rare). Here's a try push with that fixed:
https://tbpl.mozilla.org/?tree=Try&rev=d8b522213de5

Comment 15

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

That try push seems to have worked.

Comment 16

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/bbd9375c5f50

Comment 17

[Carsten Book [:Tomcat]]

hey roc, sorry had to back this out again, seems it was causing https://tbpl.mozilla.org/php/getParsedLog.php?id=31560952&tree=Mozilla-Inbound on windows 7 and xp debug builds, opt was fine

Comment 18

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

Somehow I managed to check in the wrong patch :-(.

Comment 19

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/6aca1511c1bb

Comment 20

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/6aca1511c1bb

Comment 21

[Ioana (away)]

https://hg.mozilla.org/mozilla-central/diff/6aca1511c1bb/layout/generic/test/test_bug938772.html