Closed
Bug 325344
Opened 19 years ago
Closed 19 years ago
Javascript access to HTML-Frame broken (only with XHTML!)
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 314922
People
(Reporter: m.suencksen, Unassigned)
Details
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" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="de" xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
<head>
<script>
setTimeout('alert(top.frames.evil1.document)', 1000);
</script>
</head>
<frameset rows="20%,*">
<frame src="blubb.html" name="evil1" />
<frame src="bla.html" name="evil2" />
</frameset>
</html>
--- 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•19 years ago
|
||
See http://www.w3.org/TR/xhtml1/#h-4.10
This probably isn't supposed to work the way you expected.
|
|
||
Comment 2•19 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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
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 https://bugzilla.mozilla.org/show_bug.cgi?id=183683 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•19 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 http://developer.mozilla.org/en/docs/Mozilla'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 http://www.hixie.ch/advocacy/xhtml for a discussion on HTML vs XHTML.
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.
Description
•