Closed Bug 147070 Opened 23 years ago Closed 15 years ago

Problem with nested <iframe>

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: heller, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(1 file)

Testcase
352 bytes, text/html
Details
I have created a website that I *believe* follows the standards for HTML 4.01, using an <iframe> tag. I used the information on the page at the URL http://www.w3.org/TR/REC-html40/present/frames.html. What happens is the both the src= tag AND the body of the <iframe> is displayed, or rather *part* of the body is displayed. The URL above contains the HTML code that Mozilla seems to not handle properly. BTW: I'm using Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.5) Gecko/20011012, in case it matters.
Which part of the iframe's child content is shown? Also, see http://validator.w3.org/check?uri=http%3A%2F%2Fwww.deepsoft.com%2Fcgi- bin%2Fdeepwoods.cgi&charset=%28detect+automatically%29&doctype=Inline -- this page is not anywhere close to being valid HTML; for one thing it has the wrong doctype.
OK, I fixed the code up some. It still fails to validate, but the 'errors' don't appear valid to me: the validator does not like the presence of a <body> tag in a FRAMESET DOCTYPE without a <frameset>...</NOFRAMES>...</NOFRAMES></FRAMESET>, but I need the FRAMESET doctype to handle the <IFRAME> tag, which needs to be in <BODY>, which seems not to be allowed in a FRAMESET DOCTYPE...... Note that all of the HTML code is generated by CDI scripts. The validator seems to also have problems with '&' in the query part of URLs, even when the URLs are properly quoted. These appear (to me) to be bugs in the W3C validator. As to what is being displayed (that shouldn't) it appears to be everything after the first (of three) </iframe> tags. Note that there are two embedded <iframe>...</iframe> blocks inside the outer <iframe>...</iframe>. These are for banner ads. Simplistictly speaking, the document is structured like this: <html> <head> </head> <body> <iframe src="..."> <table> <tr> <td width="165"...> </td> <td> <iframe src="..."> </iframe> <!-- Mozilla 0.9.5 seems to think that this </iframe> closes the *first* </iframe> <!-- everything below here is displayed, after the content of the URL specificed in the src= element of the *first* </iframe> --> </td> </td width="130"> <iframe src="..."> </iframe> </td> </tr> </table> </iframe> </body> </html>
Target Milestone: --- → mozilla0.9.5
> the validator does not like the presence of a <body> tag in a FRAMESET DOCTYPE That's because that doctype is for frameset documents. This is not a frameset document. The <iframe> changes nothing -- the whole point of <iframe> is that it can be used in an otherwise normal non-frameset HTML document. > The validator seems to also have problems with '&' That's because you can put entities in the strings. So you need to escape "&" as "&amp;", since "&alpha;", for example, is a valid way to put an actual greek letter in the query string. All of which should not be affecting this bug, really. ;) Over to parser; I just looked and we should not be using CTextToken::ConsumeUntil inside <iframe>, but I could be wrong about that... It certainly _sounds_ like we're using it...
Assignee: jkeiser → harishd
Status: UNCONFIRMED → NEW
Component: HTMLFrames → Parser
Ever confirmed: true
QA Contact: amar → moied
> Over to parser; I just looked and we should not be using > CTextToken::ConsumeUntil inside <iframe>, but I could be wrong about that... > It certainly _sounds_ like we're using it... Yeah, It *should* be doing a 'balanced' skip instead of a 'stop at first </iframe>' type of skip. It should handle nested <iframe>'s and it appears not be handling them properly..
Because of various *other* issues, I changed the site in ways that effectively avoids this partitular bug. Just in case someone visits the site and wonders "What is wrong? Looks OK to me." Let me know if a test case is needed, and I will create one.
Please do and attach it to this bug using http://bugzilla.mozilla.org/attachment.cgi?bugid=147070&action=enter -- that will allow testing and verification of fixes if nothing else.
I created a test page at the URL http://www.deepsoft.com/cgi-bin/iframe.cgi that invokes the bug, which seems to a problem Mozilla has with nested <iframe> blocks.
URL: http://www.deepsoft.com/cgi-bin/deepw... → http://www.deepsoft.com/cgi-bin/ifram...
Um... That page looks completely identical in IE5 and Mozilla. There is also no way to tell whether the testcase passes or fails... could you make the text that should _not_ show up be something like "THIS TEXT SHOULD NOT SHOW UP" or something? That way it's obvious at a glance....
I added some text that should ONLY show up if viewed with a browser that does NOT support the <iframe> tag, or one that mis-supports the <iframe> tag. I guess it is possible that IE is broken too... What *should* show up is something like this: Navigation <a 468x60 ad banner image> <a 120x600 Frame 'skyscraper' ad image> <Some header navigation and logo images> <small image> Welcome To Deepwoods Software Deepwoods software is a small consulting and shareware business, specializing in database and systems software using C, C++, and Tcl/Tk in a UNIX environment. Deepwoods also produces GPL shareware and freeware. These programms include software for home libraries, role playing gamers, and model railroaders. These programs and packages can be downloaded here and other places for free. Ask a free question! Learn more about Deepwoods Software. Find out about the products available for free download. Read and sign the guest book. Or try out the Discussion Areas. <Tcl/Tk feather logo> Copyright... And that should be all. The 'Navigation Frame' in the *real* site has a tall stack of nagigation buttons and the skyscraper add is also a 'tall' object. Compare what http://www.deepsoft.com/cgi-bin/deepwoods.cgi displays vs. what http://www.deepsoft.com/cgi-bin/iframe.cgi displays. Presently http://www.deepsoft.com/cgi-bin/deepwoods.cgi does NOT use the <iframe> tag (except in the skyscraper ad served by AdvertWizard), and does not include the 468x60 ad banner at all. I believe what was happening when I had the 468x60 ad banner, it was using an <iframe> and Mozilla (0.9.5) was *prematurely* closing the <iframe> block used for the main content with the </iframe> tag on the banner ad. My <iframe>'s src element loads a <frameset> and the body of the <iframe> simulates the <frameset> with a nested set of <table>s, which in turn include the ad images which are handled with <iframe>s. I changed http://www.deepsoft.com/cgi-bin/deepwoods.cgi to just use the nested <table>s -- I presently have the <frameset> code disabled (there were other issues with the embedded <frame>s in the <frameset> in the <iframe> (not a browser problem, but website usability issues, involving nesting scrollbars with smaller browser windows).
Attached file Testcase —
Yep, this looks like it's buggy in IE5 as well... IE seems to not allow nesting <iframe> at all (it shows two iframes in that testcase).
Summary: Problem with <iframe> with embedded <table> → Problem with nested <iframe>
Target Milestone: mozilla0.9.5 → ---
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration -----
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → Future
Keywords: testcase
Depends on: 242298
Assignee: harishd → nobody
Status: ASSIGNED → NEW
QA Contact: moied → parser
WONTFIX per HTML5.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: