Javascript access to HTML-Frame broken (only with XHTML!)




13 years ago
13 years ago


(Reporter: m.suencksen, Unassigned)


Firefox Tracking Flags

(Not tracked)




13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

In Firefox 1.5, with Content-Type XHTML, frame objects cannot be accessed by javascript anymore. (Maybe broken-by-design?)

Reproducible: Always

Steps to Reproduce:
Example file "test.xhtml", source code:  ---snip---

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
                                                                                                                                                               <html lang="de" xmlns="" xml:lang="de">
  setTimeout('alert(top.frames.evil1.document)', 1000);
 <frameset rows="20%,*">
  <frame src="blubb.html" name="evil1" />
  <frame src="bla.html" name="evil2" />

--- snip ---

!!Make shure "Page Info" really shows XHTML as content-type for the following file!! Result: Firefox Javascript Console shows: "top.frames.evil1 has no properties" 
Actual Results:  
Frame object has gone missing. With Mozilla 1.7.12 there is no problem (with content-type either HTML or XHTML), with Firefox 1.5 there is no problem as long as the file's content-type is set to HTML but bombs with XHTML.

Expected Results:  
No javascript error even with file-content-type set to XHTML.

Comment 1

13 years ago

This probably isn't supposed to work the way you expected.

Comment 2

13 years ago
I looked into this some more.  Firefox's behavior was changed with bug 183683.  Duping to a related bug.

*** This bug has been marked as a duplicate of 314922 ***
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 3

13 years ago
Thanks a lot for providing the resolution! :-)

For my web-site it is an easy fix now but - as a more general thought - was it necessary to introduce such an incompability for Firefox? After reading the rationale in I felt it was quite radical to drop the frame/name attribute since it still has a deprecated status just like framesets altogether. The original bug only pointed out that frame/id support was ailing.

Comment 4

13 years ago
The developers may have a better answer, but my take on the situation:

While the 'name' attribute has deprecated status, the use of 'id' is mandated in the spec.  So as a practical matter I'm not sure what use leaving the 'name' attributes in serves, other than allowing pages to be written that are compatible with HTML without causing validation errors.  In any case, the Firefox 1.0 behavior was incorrect.

Regarding compatability, Firefox has a 'quirks' rendering mode to match old Netscape and IE behavior (see's_Quirks_Mode).  XML/XHTML on the other hand does not have the same amount of [incorrect] legacy content, so there's less of a reason to support documents that don't meet the requirements set forth in the spec (and such documents are always processed in 'strict' mode).

You may also want to read for a discussion on HTML vs XHTML.

Comment 5

13 years ago
I am seeing the points you make and do agree. Still, from a support viewpoint I have to consider it somewhat unnecessary to ruin end-user experience of Firefox just because a deprecated feature is dropped as soon as possible. 
You need to log in before you can comment on or make changes to this bug.