156178 - NOLAYER tags should be ignored by Mozilla.

Status: VERIFIED DUPLICATE of bug 61443

(Core :: DOM: HTML Parser, defect)

Description

[Huazhang Shao]

Mozilla should ignore NOLAYER tags, as if they did not exist. LAYER tags are
already meaningless in Mozilla. NOLAYER tags should also be meaningless.

The following two parts should have the same effect.

1)
<div style="background-color:red;">
ABC
</div>

2)
<nolayer><div style="background-color:red;"></nolayer>
ABC
<nolayer></div></nolayer>

But actually, they do not. That means <nolayer> and </nolayer> are not totally
ignored by Mozilla.

I think this is a bug.

Comment 1

[Brant Gurganus]

I believe the problem is your nesting in your second case.  It should more
appropriately be:
<nolayer><div style="background-color:red;">
ABC
</div></nolayer>

I did not test this, but that is the proper nesting of those.  You cannot start
an element within another element and end it outside the surround element.

Comment 2

[Boris Zbarsky [:bzbarsky]]

We should ignore them to the extent that we should ignore any other unknown HTML
tags. This does not negate the fact that the document should be well-formed,
since well-formedness checking needs to happen after tokenization and before
content model construction...

<foo><div></foo>
<foo><div></foo>

acts just like the same thing with <nolayer>.

In any case, how exactly is the <nolayer> case different from the other one
here?  I just checked, and they look identical to me..

Comment 3

[Huazhang Shao]

Attachment: Testcase for Bug #156178

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: screenshot of that testcase

Comment 5

[Huazhang Shao]

It seems that the bug has been fixed in recent builds. I was using Build ID
200205312. I'll download the latest build and test it.

Comment 6

[Huazhang Shao]

In Mozilla (Build ID: 2002070708}, the bug does not exist. I'm glad to know it
has been fixed. (But I don't know when it was fixed.)

Comment 7

[Olivier Cahagne]

Reopening to mark it WFM as Fixed would mean a specific patch attached to this
bug report actually fixed it.

Comment 8

[Olivier Cahagne]

Marking WFM (unless one can find the proper dupe)

Comment 9

[Marcus Campbell]

Dupe of bug 61443?

Comment 10

[Huazhang Shao]

I just found Netscape 7.0 still has the bug. The version string is
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0

I know Netscape 7.0 is different from Mozilla. But Netscape 7.0 seems to be
based on Gecko/20020823. I do not have the latest build of Mozilla. Can anyone
check whether this bug came back to Gecko engine recently?

Comment 11

[Boris Zbarsky [:bzbarsky]]

That's Gecko/20020823 off the 1.0 branch, not the trunk.  This bug was never
fixed on branch (and yes, this is a dup).

*** This bug has been marked as a duplicate of 61443 ***

Comment 12

[Jerry]

the patch for 61443 has been checked into trunk, not 1.0 branch.
And netscape 7.0 is based on 1.0 branch, so you can still see the problem.

Comment 13

[Huazhang Shao]

Thanks for the explanation. Well, now my only question is
	When will the patch be checked into 1.0 branch?

I really hope the bug can be fixed in Netscape 7 series ASAP. It breaks many web
pages in our project.

Comment 14

[Boris Zbarsky [:bzbarsky]]

This is probably never going into the branch... the next Netscape release should
be off the trunk in any case...

Comment 15

[Marcus Campbell]

Verified.

Comment 16

[Jerry]

The patch for it has been checked into OEM branch.
netscape 7.0 for solaris is based on OEM branch, it will work fine.