487398 - <object>-element within <video>-element is not ignored

Status: REOPENED

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

Description

[Wicher Minnaard]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3) Gecko/20090329 Gentoo Firefox/3.1b3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3) Gecko/20090329 Gentoo Firefox/3.1b3

This is a spinoff from bug 486673 .
Suppose I have a Theora video as an <object>-element. When this is wrapped inside a <video>-element with another Theora video, both video's will be playing. The video in the <object>-element is not visible, but the sound is audible.
I haven't found any documentation on this but according to https://bugzilla.mozilla.org/show_bug.cgi?id=486673#c8 the comment by Chris Double, this is a serious bug.

Reproducible: Always

Steps to Reproduce:
Open attached testcase with Firefox => 3.1.

Actual Results:  
1. Top video in the <video> element is shown. It's paused at frame 0.
2. Meanwhile, the video in the <object> element is playing. You can't see it, but you will hear the sound playing.
3. When you right-click the top video (from the <video> element) you can choose
"play" and the video will start playing. Sound from the two videos is mixed
together.


Expected Results:  
Only the video in the <video>-element should play. The <object>-element within the <video>-element should be ignored.

Take a look at bug 486673 to see why this breaks the user experience and in what ways this could be solved. The short of it is that it's now next to impossible to have a webpage play Theora video the right way in both Firefox <3.1 and >= 3.1.

Comment 1

[Wicher Minnaard]

Attachment: Testcase for simultaneous <video> and <object> theora video playing

Comment 2

[Daniel.S]

This is a issue on 3.1 and trunk.

The video in the video element doesn't play, but the one in the object element (although invisible) is playing at least the audio part.

Comment 3

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

We shouldn't be constructing frames for the content inside the <video> element. This is pretty bad since it creates crazy behaviour for fallback.

Comment 4

[Anne (:annevk)]

Note that per HTML5 you should. (There are no special requirements.)

Comment 5

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

We shouldn't be rendering the children of the <video> element, surely?

Comment 6

[Anne (:annevk)]

It's no different from <div style=display:none><object ...></object></div> or <iframe><object ...></object></iframe> (in XML). Scripts still execute and I would actually expect Flash and such to still play. (I don't really have an opinion on whether this is optimal, but as far as I can tell this is what is required.)

Comment 7

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

display:none <object> elements containing plugins do not run the plugin in Gecko. It's a bug, but an old and huge enough bug that it isn't going to be fixed for 1.9.1, certainly.

Comment 8

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

This screws up fallback badly, so I'm going to try to fix it...

Comment 9

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

Oh, I misunderstood this bug completely!

In the testcase, we don't use any plugins. The <object> instantiates a subdocument containing our own Ogg player. That works even though it's effectively display:none, as it should per spec. So I don't think we have a real bug here.

One way for authors to avoid this problem is to *only* use the <object> element. That will play in Firefox and in other browsers with the right plugins. Now that bug 486673 is fixed, that's not too bad.

Another option is to use JS so the <object> element is only created when the <video> element would not work (by calling canPlayType, for example).

I agree that the spec behaviour is suboptimal in some sense, but I'm not sure how I would change the spec to avoid this.

Comment 11

[Toni Ruottu]

Would using object tag cause Firefox 3.5 to play an ogg vorbis file with the integrated player? Trying to make that happen was the reason why I was using audio tag and run into the problem of not being able to have a fall back embed tag inside it.

Comment 12

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

No, we'd play the ogg Vorbis file twice, once in <audio> and once in <object>. But if you just use the <object>, that might work for you.

Comment 13

[Toni Ruottu]

That is what I was planning to do. My question was, if that works when I don't have an ogg vorbis player installed?

Use case:
MacOsX does not have an ogg vorbis player installed by default.
Using <audio src="song.ogg">  in ff 3.5 still enables Mac users to hear the song.

Question:
Does <object data="song.ogg"> in ff 3.5 enable the Mac users to hear the song?
Lets assume they still have not installed an external player.

Comment 14

[John Drinkwater (:beta)]

Doesn’t this deserve discussions back with HTML5, and a spec adjustment?
For now it means fallback will confuse developers (because it doesnt follow previous methods) *and* it wastes bandwidth by fetching two media resources..

Comment 15

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

Yes, please go ahead.

Comment 17

[John Drinkwater (:beta)]

It appears changes have been made before I brought them up:

‘Make applet, object, and embed not instantiate if they have video or audio ancestors.’
http://html5.org/tools/web-apps-tracker?from=3485&to=3486

Comment 18

[Paul Swartz]

If this change was made to the spec, I'd think that the bug should not longer be RESOLVED INVALID.

Comment 19

[cajbir (:cajbir)]

From http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-object-element

"If the element has an ancestor media element, or has an ancestor object  element that is not  showing its fallback content, or if the element is not in a Document  with a browsing context, or if the element's Document  is not fully active, or if the element is still in the stack of open elements of an HTML parser or XML parser, then jump to the last step in the overall set of steps (fallback)."

I've reopened this bug.

Comment 20

[Vlado P.]

This bug is especially annoying when there are several audio tracks on one page: they'll all start to play simultaneously in the background - unstoppable, unless you leave the page or turn off your speakers.

Comment 21

[Paul Adenot (:padenot)]

This works for me on the current nighly.

Comment 22

[nabber00]

I discovered this is still a problem in 7.0.1 (current stable release).  Its possible its fixed in nightly, I have not checked.  I have a page that can be used to test, proper behavior is that nothing should autoplay.  Note that this is all valid HTML4, objects within objects, no audio/video tags:

http://nabber.org/?RWwYBg

Bugs that seem to be related:

Bug 250855 - Mozilla should respect autoplay=false command in embed tag.

Bug 516070 - <object> tag autoplays when told not to

Comment 23

[John Drinkwater (:beta)]

(In reply to nabber00 from comment #22)
> I discovered this is still a problem in 7.0.1 […]
> http://nabber.org/?RWwYBg

and still in Aurora 9.0a2, it autoplays the nested object, you can hear audio but you see nothing.

Comment 24

[nabber00]

Firefox 9.0 was just released, my test page is still misbehaving.