286914 - Mozilla inappropriately exposes OBJECT element contents in DOM

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[tbarham]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This is, in some way, related to bug 250012. That was resolved as invalid, and 
I understand why.

This is essentially the reverse case - HTML within an object element that has 
been successfully rendered is exposed in the DOM.

The w3c HTML 4.01 spec states (at 
http://www.w3.org/TR/html4/struct/objects.html#h-13.3.1): "The user agent must 
first try to render the object. It should not render the element's contents, 
but it must examine them in case the element contains any direct children that 
are PARAM elements (see object initialization) or MAP elements (see client-
side image maps)."

In Mozilla/Firefox, the HTML within an OBJECT element that is successfully 
rendered is, appropriately, not rendered, but it *IS* exposed in the DOM. I 
believe an appropriate interpretation of the w3c spec would be that HTML 
within OBJECT elements should be completely ignored in this case. Otherwise it 
can be very hard to determine which OBJECT the browser is actually rendering 
(and which OBJECT should be subsequently controlled via JavaScript, if 
necessary.

Finally, the HTML within an OBJECT element serves absolutely no purpose if the 
browser can render the OBJECT element, so it serves no purpose exposing it in 
the DOM.

If the current behavior is deemed "correct behavior", then how are we to 
determine what the browser has actually rendered?

Reproducible: Always

Steps to Reproduce:
1. Create HTML that contains an OBJECT element that the browser can render. 
Give the OBJECT element some id.
2. Stick a DIV element with some text inside the object element, as example 
alternate HTML. Give the DIV element some id different to the OBJECT element.

For example:

<object id="obj1" width="640" height="480" type="application/x-shockwave-
flash" data="">
<div id="div1">This is alternate text.</div>
</object>

3. Include some JavaScript code to display document.getElementById ( "<object 
id>" ) and document.getElementById ( "<div id>" ) - note that both cases 
return a valid object reference, even though the div is not rendered.

Note that this is a trivial example - in a real example, there might be an 
alternate <object> element within the outer <object> element, and you might 
need to be able to control the functionality of whichever object element 
renderes, in JavaScript code. So being able to easily tell which object the 
browser has rendered is very important.
Actual Results:  
A valid object reference is returned for the div inside the object element.

Expected Results:  
Returned null.

Comment 1

[Vlad Alexander]

This bugs affects our ability to deliver an accessible (JavaScript free)
solution in FF. With the release of FF 1.5, our plug-in software will use the
following construct to submit data to the server.

<object name="abc">
	<textarea name="abc"></textarea>
</object>

Because of this bug, data from both the <object> element and the <textarea>
element will be sent to the server.

Here is a test case:
http://xstandard.com/misc/mozilla/alternate-content1.asp

Comment 2

[Anne (:annevk)]

This is the way HTML5 will work. Web Forms 2 already states that such form controls should be submitted.

Comment 3

[Hallvord R. M. Steen]

(In reply to comment #2)
> This is the way HTML5 will work. Web Forms 2 already states that such form
> controls should be submitted.

Sorry Anne, where in WF2 do you find this statement? I find nothing explicitly mentioning this issue. I do note that "form elements inside rendered OBJECT tags" are not among the exceptions listed in http://www.whatwg.org/specs/web-forms/current-work/#successful but I don't recall this being discussed so it's just something noone brought up AFAIK.

Comment 4

[Hallvord R. M. Steen]

I think two issues are confused here. Fallback contents should be available in the DOM. I see no reason why they should not, the problem the original reporter complains about must be solved some other way (for example, many plugins will add properties to the DOM object that can be used to detect they are loaded)

Whether or not to submit form elements inside OBJECT is a separate issue and should have a separate bug.

Comment 5

[Hixie (not reading bugmail)]

This is invalid. The DOM is just the DOM as it was parsed, it should contain everything in the page, regardless of whether a particular object is available or not at any particular time (which can change on the fly in various ways).

Comment 6

[Vlad Alexander]

Entered a new bug 335567 to describe incorrect behaviour of sending data to the server from alternate content if the object element can be rendered.