332383 - named frames in application/xhtml+xml document not reflected as window.frames.frameName

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Martin Honnen]

The test case at
<http://home.arcor.de/martin.honnen/mozillaBugs/domLevel0/framesFrameName1.xhtml>
is a XHTML 1.0 frameset document served as application/xhtml+xml with two frame elements with a name attribute (e.g. name="frame1").
Those named frames do not show up as named properties in the window.frames collection (e.g. window.frames.frame1), the created frame window objects do not have the proper name property (e.g. frame1) and the frames are not targettable with a link (e.g. <a target="frame1" href="someURL" does not open in the frame).

The same document served as text/html is here:
<http://home.arcor.de/martin.honnen/mozillaBugs/domLevel0/framesFrameName1.html>
There the frames show up in the window.frames collection as named properties, the created frame window objects have the proper name property and the frames are targettable with a link.

I don't think there should be any difference in regardance to the frame handling depending on the content type, the application/xhtml+xml case should behave the same as the text/html test case as this is all DOM level 0 (window.frames and window.name) respectively XHTML 1.0 (target, frame name).

Tested with Firefox 1.5.0.1 release (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1) and with a Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1).

Comment 1

[WADA:World Anti-bad-Duping Agency]

When I executed following script at URL bar of XHTML 1.0 test case, all properties of window.frames[N] returned "undefined".
(Seamonkey 2006033009-trunk/Win-2K).
 [ Merge into single line before execution ]
 javascript: m=''; obj=window.frames[0]; /* Same result when frames[1] */
 for (x in obj) { m+=x+','+String(obj.x)+'\n'; } alert(m);
This indicates that even basic window.frames[N].name becomes "undefined".

(Q1) Does problem occur even when XHTML 1.1?
(Q2) Can next be a workaround?
     - Use HTML for main page(frameset/frame) (As you say, no problem when HTML)
     - Use XHTML for page loaded in a frame, if XHTML is required.

Comment 2

[Martin Honnen]

(In reply to comment #1)

> (Q1) Does problem occur even when XHTML 1.1?

XHTML 1.1 does not allow frameset documents and frames so I am not sure why you ask that question.

> (Q2) Can next be a workaround?
>      - Use HTML for main page(frameset/frame) (As you say, no problem when
> HTML)
>      - Use XHTML for page loaded in a frame, if XHTML is required.

For a simple case that could be a workaround but in general if you want to make the transition to XHTML parsed as application/xhtml+xml then you want to do it for all documents and not have some mixture of text/html and application/xhtml+xml. In a real web application you might look at HTTP accept headers and decide to serve application/xhtml+xml or text/html depending on what the browser accepts. 

Comment 3

[Martin Honnen]

Here is a further test case testing a XHTML 1.0 document containing a named iframe element. Again with the application/xhtml+xml test case
<http://home.arcor.de/martin.honnen/mozillaBugs/domLevel0/framesIFrameName1.xhtml>
Mozilla (tested with Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060331 Firefox/1.6a1) and with Firefox 1.5.0.1 release) fails to expose the iframe in the window.frames collection as window.frames.iframe1, fails to expose the iframe name as a property on the iframe window object, and fails to make the iframe targettable by a link.

The same document served as text/html 
<http://home.arcor.de/martin.honnen/mozillaBugs/domLevel0/framesIFrameName1.html>
works flawlessly, window.frames.iframe1 is a window object, the iframe window object has the proper name and the iframe is targettable by a link

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is basically bug 488247.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.