<nolayer><div></nolayer> != <foo><div></foo>

RESOLVED FIXED

Status

()

P3
major
RESOLVED FIXED
18 years ago
17 years ago

People

(Reporter: brian, Assigned: harishd)

Tracking

({fixedOEM, testcase})

Trunk
fixedOEM, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
I'm not sure if this bug is a problem at wrox or with Mozilla.  I'm afraid I
don't have the time to examine the code.  The code is rendered properly in
Netscape 4.7.  If you look in the upper right corner, the image overlays some of
the navigation text.  They use CSS and tables for layouts.  Thanks!
Probably caused by the following code:

<layer><nolayer><div></nolayer> content <nolayer></div></nolayer></layer>

This is certainly not properly nested...  And the div in question does have css
positioning arguments applied to it that should move it down further.  But I am
guessing that <div> is closed to nest with <nolayer>, so the content is not
inside the <div>
According to http://sites.netscape.net/ekrockhome/standards.html
these *tags* should be ignored totally, quote:

"Netscape 6 silently ignores the <LAYER>, </LAYER>, <ILAYER>, </ILAYER>, 
<NOLAYER>, and </NOLAYER> tags and renders the HTML page as if
those 6 tags were not present (i.e. as if the file had been edited to remove 
those 6 tags only)"

So, as I see it "<nolayer><div></nolayer>" should be equivalent to
"<foo><div></foo>" but it isn't.

Also, Mozilla is not consistent with how IE interprets <layer> and <nolayer>
(which ignores them as any other *unknown* tag). Wasn't this the intended
behaviour when it was decided not to support layers?
Assignee: clayton → harishd
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
OS: Linux → All
QA Contact: petersen → janc
Hardware: PC → All
Summary: Possible Mislayout of Image & Text (CSS & Tables) → <nolayer><div></nolayer> != <foo><div></foo>
Keywords: testcase
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 4

18 years ago
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 -----
Target Milestone: mozilla0.9 → Future

Comment 5

18 years ago
updated qa contact.
QA Contact: janc → bsharma
(Reporter)

Comment 6

18 years ago
I think a bug like this should be fixed for a full lizard
Keywords: mozilla1.0
Created attachment 35953 [details]
Testcase #2

Updated

18 years ago
QA Contact: bsharma → moied

Comment 8

17 years ago
*** Bug 105911 has been marked as a duplicate of this bug. ***

Comment 9

17 years ago
*** Bug 107360 has been marked as a duplicate of this bug. ***

Comment 10

17 years ago
Suggest add to milestone : mozilla 1.0

As its darn anonying on older websites as it break the <noframe><iframe> code of
old for parsing on nonlayer browsers

Comment 11

17 years ago
as http://www.mozilla.org/docs/web-developer/upgrade_2.html said,
Gecko renders the HTML as if the LAYER, ILAYER, and NOLAYER tags were not there.

but when look into source of nsHTMLList.h, there are still nolayer,ilayer,layer 
in list.

so we should remove them from mozilla code.

Comment 12

17 years ago
Created attachment 80732 [details] [diff] [review]
remove nolayer from mozilla code

Comment 13

17 years ago
I make an simple patch just remove nolayer tag from mozilla code,
it works for me to access Testcase, and testcase #2.

when parser meet <nolayer>, it will regard it as unknown tag or userdefined tag.

Keywords: patch, review
Target Milestone: Future → ---
Comment on attachment 80732 [details] [diff] [review]
remove nolayer from mozilla code

This patch seems good to me.  Harish, could you r=?

There are a couple of other non-documentation places--not in the Mozilla code
proper, but elsewhere--where nolayer is referenced where we do things.	One of
them (a Perl script) appears to be capable of generating parts of 
nsElementTable.cpp.

I agree with this bug's philosophy that nolayer should be treated the same as
foo.  And ilayer and layer.  Our browser doesn't know about them, it should act
the part.  (Must file a bug on those if it's not already filed.)

I disagree with how we *do* handle containment for unknown tags, though. 
Containment matters because unknown tags can carry style.  However, this is a
separate bug too.
(Assignee)

Updated

17 years ago
Attachment #80732 - Flags: review+
(Assignee)

Comment 15

17 years ago
Comment on attachment 80732 [details] [diff] [review]
remove nolayer from mozilla code

>-TagList  gBodyKids={9, {eHTMLTag_dd,eHTMLTag_del,eHTMLTag_dt,eHTMLTag_ins,
>-                        eHTMLTag_noscript,eHTMLTag_nolayer,eHTMLTag_script,eHTMLTag_li,eHTMLTag_param}}; // Added PARAM for bug 54448
>+TagList  gBodyKids={8, {eHTMLTag_dd,eHTMLTag_del,eHTMLTag_dt,eHTMLTag_ins,
>+                        eHTMLTag_noscript,eHTMLTag_script,eHTMLTag_li,eHTMLTag_param}}; // Added PARAM for bug 54448
> TagList  gButtonKids={2,{eHTMLTag_caption,eHTMLTag_legend}};

Add a comment why nolayer is removed and also mention the bug number.

Comment 16

17 years ago
who can give sr?
and I will file another bug to remove ilayer, layer tag from mozilla source
after it.
(Assignee)

Comment 17

17 years ago
Jerry: Take a look at the documentation in
http://www.mozilla.org/hacking/reviewers.html.

FYI: jst@netscape.com can sr= parser changes. Also, cc reviewers@mozilla.org.
Comment on attachment 80732 [details] [diff] [review]
remove nolayer from mozilla code

sr=jst
Attachment #80732 - Flags: superreview+
Comment on attachment 80732 [details] [diff] [review]
remove nolayer from mozilla code

sr=jst
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
Whiteboard: branchOEM

Updated

17 years ago
Whiteboard: branchOEM → branchOEM+

Updated

17 years ago
Whiteboard: branchOEM+ → branchOEM+ fixedOEM

Updated

17 years ago
Keywords: review
Whiteboard: branchOEM+ fixedOEM → fixedOEM
*** Bug 156178 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: fixedOEM
Whiteboard: fixedOEM
You need to log in before you can comment on or make changes to this bug.