Closed Bug 318557 Opened 19 years ago Closed 19 years ago

self closing iframe tag stops processing of page (using <iframe ... /> instead of <iframe...> </iframe>)

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 158667

People

(Reporter: xanthraxoid, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)
Build Identifier: multiple, tested versions include "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)", "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5", and remarkably "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

Any page which includes a self-closing iframe tag (<iframe ... />) stops processing immediately after the iframe, as is demonstrated by the attached example. This file validates as xhtml1.0 according to the w3c validator (link included in example) but equally I get the same behaviour if I just make the page anonymous some-version-of-html.

Reproducible: Always

Steps to Reproduce:
1. view page containing self-closing iframe
2. wonder where the rest of your page went


Actual Results:  
After viewing the example, the text "... this text does not appear" does not appear. It looks like the iframe tag is not considered self closing and therefore the rest of the page is contained within the iframe tag and not displayed as the iframe itself can be displayed. Presumably the gecko engine at some point rolls its eyes and says "you didn't close your iframe tage before the end of the file, and where did your </body> and </html> tags go?". The xhtml validator says the self-closing tag is valid.

Expected Results:  
I expected the iframe to be considered self-closing and for the rest of the page to be processed corectly. 

I've marked this bug as "normal" rather than "minor" because the workaround, though simple, is in the control of the website not the browser user.

This is the text of the example, in case the online version isn't accessible for any reason.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title> A page that demonstrates an iframe handling bug </title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
</head>
<body>
<p>
  <a href="http://validator.w3.org/check?uri=referer">
    <img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0 Transitional" height="31" width="88" />
  </a>
</p>
<p> This text appears and ... </p>
<iframe src="http://www.google.com/"></iframe>
<p> ... so does this text, but ... </p>
<iframe src="http://www.google.com/"/>
<p> ... this text does not appear! </p>
</body>
</html>
Just thought I'd add, I also get the same behaviour in Mozilla classic, but I'm not sure how to represent that in the affected product field (If I select Core, which seems to make most sense, all the milestones are for mozilla classic. Which "product" corresponds to gecko?)

Anyway, here are  the user agent lines from a couple of other geckos that don't like it.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Ubuntu package 1.0.7)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Debian/1.7.12-0ubuntu05.04

See bug 158667 comment 5.

*** This bug has been marked as a duplicate of 158667 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.