Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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




Audio/Video: Playback
8 years ago
5 months ago


(Reporter: Wicher Minnaard, Unassigned)




Firefox Tracking Flags

(Not tracked)




(1 attachment)



8 years ago
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 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

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

8 years ago
Created attachment 371654 [details]
Testcase for simultaneous <video> and <object> theora video playing


8 years ago
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general →

Comment 2

8 years ago
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.
Ever confirmed: true
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Keywords: testcase
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
We shouldn't be constructing frames for the content inside the <video> element. This is pretty bad since it creates crazy behaviour for fallback.
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1?
Flags: blocking1.9.1+

Comment 4

8 years ago
Note that per HTML5 you should. (There are no special requirements.)
We shouldn't be rendering the children of the <video> element, surely?

Comment 6

8 years ago
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.)
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.
This screws up fallback badly, so I'm going to try to fix it...
Assignee: nobody → roc
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.
Last Resolved: 8 years ago
Flags: wanted1.9.1-
Flags: blocking1.9.1+
Resolution: --- → INVALID


8 years ago
Duplicate of this bug: 498345

Comment 11

8 years ago
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.
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

8 years ago
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.

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.
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..
Yes, please go ahead.


8 years ago
Duplicate of this bug: 463862
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.’

Comment 18

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

Comment 19

7 years ago

"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.
Resolution: INVALID → ---

Comment 20

7 years ago
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.
This works for me on the current nighly.

Comment 22

6 years ago
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:

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
(In reply to nabber00 from comment #22)
> I discovered this is still a problem in 7.0.1 […]

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

Comment 24

6 years ago
Firefox 9.0 was just released, my test page is still misbehaving.
Assignee: roc → nobody
Component: Audio/Video → Audio/Video: Playback
See Also: → bug 1247356


5 months ago
Blocks: 1247356
See Also: bug 1247356
You need to log in before you can comment on or make changes to this bug.