nested <noframes> elements not handled correctly

RESOLVED WONTFIX

Status

()

Core
HTML: Parser
P5
normal
RESOLVED WONTFIX
18 years ago
8 years ago

People

(Reporter: ralf.stubner, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
NOFRAMES element within another NOFRAMES like

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
	"http://www.w3.org/TR/REC-html40/loose.dtd">
<title>foo</title>
<NOFRAMES> foo <NOFRAMES> bar </NOFRAMES> snafu </NOFRAMES>

displays 'snafu'. This is true for 'standalone' viewing and if the page is
viewed within a frameset. This violates HTML 4 specifcation, as the first
</NOFRAMES> only marks the end of the second <NOFRAMES>.
(I admit that this isn't very sensible mark up, but it is valid according to
nsgmls and frameset.dtd.)

Bug found in M8 (build 1999-07-14T16) [sorry on newer version]

[BTW, the bugzilla query page might be very powerfull, but for the occasional
bug reporter like me who doesn't know all the details about the internals of
Mozilla, it is rater difficult to find a specific bug. So I am not sure, that
this bug isn't allready in the database :-(. I only found bug #2633, but the
test case isn't valid HTML anyway...]

Updated

18 years ago
Assignee: karnaze → harishd

Comment 1

18 years ago
Reassigning to Harish.

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M11

Comment 2

18 years ago
setting milestone to M11.

Comment 3

18 years ago
Looks like Gecko is doing the right thing. That is, in a document such as

<NOFRAMES> Text1 <NOFRAMES> Text2 </NOFRAMES> Text3 </NOFRAMES>

The first /NOFRAMES should close the first & second  NOFRAMES.  In doing so
"Text3" will get displayed because it will not be inside NOFRAMES anymore.
(Reporter)

Comment 4

18 years ago
Created attachment 1464 [details]
The attachement would be valid, if Harish's interpretation were correct. But it isn't valid according to nsgmls (or validator.w3.org).

Comment 5

18 years ago
Created attachment 1465 [details]
Created attachment

Updated

18 years ago
Target Milestone: M11 → M14

Updated

18 years ago
Priority: P3 → P5

Comment 6

18 years ago
Tell me what you'd expect on seeing such a mark up ?? :o)
(Reporter)

Comment 7

18 years ago
Created attachment 1507 [details]
Expected behaviour explained in attachment

Updated

18 years ago
Target Milestone: M14 → M12
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → LATER
LATERing. Although this markup may be valid in theory, I can't think of any
practical application in which there would be a reason or need to nest one
NOFRAMES element inside another. A single NOFRAMES element is used to provide
the alternative content displayed to non frames-capable browsers. Including a
second NOFRAMES element nested therein serves no purpose.

Ralf--If you can think of a practical use or need for nested NOFRAMES elements,
please let us know.

Harish--If I've overlooked something, please feel free to reopen. Otherwise
apply your time to the plenty of real-world problems we have. ;->

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 9

18 years ago
Marking verified later per last comments.

Updated

17 years ago
Summary: NOFRAMES element not handled correctly → nested <noframes> elements not handled correctly
LATER is deprecated per bug 35839.  This looks like a big fat mistake in
frameset.dtd: there's no reason for NOFRAMES to be a block element.  Reopening
and futuring, but I've written www-html-editor to see if this should be an erratum.
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M13 → Future
The word from www-html-editor is that NOFRAMES as block is a strategy adopted in
Transitional to deal with iframes.  So you could have:
<IFRAME>....</IFRAME>
<NOFRAMES>....<IFRAME>how pointless is this?</IFRAME><NOFRAMES>...</NOFRAMES>
</NOFRAMES>

In a sane world, the W3C would have made IFRAME and NOFRAMES as exclusion
exceptions for NOFRAMES, but I guess that would just have made too much sense.

Updated

14 years ago
Keywords: testcase

Comment 12

14 years ago
it seems like the debate on this issue has been resolved. 
So we need NOFRAMES implemented as a block element.
can we have this bug reassigned and set for a specific milestone. This is a
standards issue that has not been fixed.
resetting to defaults
Assignee: harishd → nobody
Status: REOPENED → NEW
QA Contact: chrispetersen → core.layout.html-frames
Why is this in layout?  This is so a parser issue -- the content model is
"wrong" (note that I think we should wontfix this, since otherwise we have to go
through hell making things like scripts inside noframes not work).
Assignee: nobody → parser
Component: Layout: HTML Frames → HTML: Parser
Depends on: 242298
Assignee: parser → nobody
QA Contact: layout.html-frames → parser
WONTFIX per HTML5.
Status: NEW → RESOLVED
Last Resolved: 18 years ago8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.