619965 - <html:audio> elements play audio, inside of SVG-as-an-image

Status: NEW

(Core :: SVG, defect)

Description

[Daniel Holbert [:dholbert]]

html <audio> elements currently play audio, inside of svg-as-an-image.  They should not.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: (testcase helper: ogg audio file)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: (testcase helper: svg w/ html:audio element)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase (though it doesn't actually reproduce bug, with all files hosted on bugzilla)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: zipped testcase

Hmm, the testcase doesn't seem to trigger the bug when hosted on bugzilla.

However, I can definitely reproduce it locally (with references in the files updated to use local versions rather than bugzilla-hosted versions).

I've zipped up a folder of the "local version" of this bug's testcase, and am attaching it here.

Comment 5

[Daniel Holbert [:dholbert]]

Marek Raida mentioned this bug to me -- his blog* was hitting this bug because he'd included one of his demos** as an image on his blog front-page.

*  http://svg.kvalitne.cz/
** http://svg.kvalitne.cz/xmastree/xmastree.svg

Comment 6

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

I'm not 100% sure this is a bug actually. Is there a reason why images shouldn't be able to play audio?

Comment 7

[Daniel Holbert [:dholbert]]

According to Marek, Opera does actually play audio in this case too (whereas Webkit and IE9 don't).  It seems odd to me, but it's apparently not a 100% settled issue among other browsers.

However, our current implementation has this additional issue: since the image persists in the image cache for an indefinite amount of time after it's been loaded, it continues to play audio indefinitely (even after the page has navigated away or its tab has been closed).  I think the only way to silence it is to manually clear your cache (or quit Firefox).

*That* definitely needs fixing. (whether it's through disabling audio entirely in images or making the audio stop more quickly)

We do pause internal animations when the last observer stops watching the image (via Image::DecrementAnimationConsumers calling Image::EvaluateAnimation which calls Image::StopAnimation).  If we want to allow audio in images, then we might want to treat it as a form of animation and stop it whenever animation stops.

Comment 8

[Robert Longson [:longsonr]]

According to SVG1.2T SVG <audio> elements play so <html:audio> should too and it should follow the same rules. http://www.w3.org/TR/SVGTiny12/multimedia.html#MediaTimeline

Comment 9

[Jonathan Watt [:jwatt]]

Maybe worth adding a mozDisableAudio="true/false"-like attribute for people to use while we wait for the specs to provide something?

Comment 10

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

I suppose an image containing an <audio> element should start playing an independent audio stream every time the image is loaded. That's not going to happen because of the way we share images.

I suppose that the same problem occurs with animation.

It seems to me we should ensure that vector image documents containing media elements or animation are never cached or otherwise reused in different contexts.

I don't think this blocks though.

Comment 11

[Daniel Holbert [:dholbert]]

FWIW, if we were to disable media-autoplay in SVG-as-an-image, I think one reasonable place to do that would be here:

> 1493 nsresult nsHTMLMediaElement::BindToTree(nsIDocument* aDocument, nsIContent* aParent,
> 1494                                         nsIContent* aBindingParent,
> 1495                                         PRBool aCompileEventHandlers)
[...]
> 1501   if (aDocument) {
> 1502     mAutoplayEnabled =
> 1503       IsAutoplayEnabled() && (!aDocument || !aDocument->IsStaticDocument()) &&
> 1504       !IsEditable();

It looks like it would be sufficient to add "&& !aDocument->IsBeingUsedAsImage()" after the IsStaticDocument check.

Comment 12

[Daniel Holbert [:dholbert]]

(er, I meant "||", not "&&")

Comment 13

[Daniel Holbert [:dholbert]]

(gah, sorry, negation-fail - confused myself. Disregard comment 12; && would be right)