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.
Steps to Reproduce:
Open attached testcase with Firefox => 3.1.
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
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.
Created attachment 371654 [details]
Testcase for simultaneous <video> and <object> theora video playing
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.
We shouldn't be constructing frames for the content inside the <video> element. This is pretty bad since it creates crazy behaviour for fallback.
Note that per HTML5 you should. (There are no special requirements.)
We shouldn't be rendering the children of the <video> element, surely?
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...
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.
*** Bug 498345 has been marked as a duplicate of this bug. ***
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.
That is what I was planning to do. My question was, if that works when I don't have an ogg vorbis player installed?
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.
*** Bug 463862 has been marked as a duplicate of this bug. ***
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.’
If this change was made to the spec, I'd think that the bug should not longer be RESOLVED INVALID.
"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.
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.
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.
Firefox 9.0 was just released, my test page is still misbehaving.