33397 - <NOSCRIPT> in a page interferes with residual style handling (recent regression?)

Status: VERIFIED FIXED

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

Description

[John Morrison]

Overview Description:
  <NOSCRIPT> in a page interferes with residual style handling.

Steps to Reproduce:
1) load the attachment (to follow)
2) compare the page using mozilla and Nav4.x

Actual Results:
  'residual style' is not applied to HTML that follows a NOSCRIPT element.

Expected Results:
  'residual style' is applied as expected.

Reproducibility: always

Build Date & Platform Bug Found:
  2000032609 win98

Additional Builds and Platforms Tested On:
  also occurs on:
    2000032609 macos
  does not occur on:
    2000032409 linux (I couldn't get the build for 3/25 and 3/26 to launch).

Additional Information:
  uh, the commercial build for mar26 on win32 does not actually run, unless
  you supply your own netscape.xul in 
    c:/Program Files/Netscape/Netscape 6/chrome/navigator/content/default/
  See bug #33204 (if it matters to you).

Comment 1

[John Morrison]

Attachment: testcase; sample HTML before and after the NOSCRIPT element

Comment 2

[rickg]

*** Bug 36270 has been marked as a duplicate of this bug. ***

Comment 3

[rickg]

Testcase:

<NOSCRIPT></NOSCRIPT>
<A HREF="two">
  <H2>U-571 Review</H2>
</A>

Comment 4

[Jim Roskind]

Since the other bug that the PDT rated dogfood (36270) was resolved as a dup of
this one, I'm putting the same dogfood marking here.

Note that standard commercial content (from San Jose Merc News) is no longer
readable because of this regression :-(.  That was why it earned a dogfood
rating.  See the earlier 36270 bug for the sample file.  Without this bug fixed,
I can't even read my daily email from San Jose Merc :-( :-(.

Comment 5

[rickg]

Sorry Jim -- I'm still not taking this as dogfood. We have a number of bugs that 
could be called dogfood by your metric, but I wouldn't hold up beta2 for any of 
them. I will do my best to close this out in m16.

Comment 6

[Doron Rosenberg (IBM)]

*** Bug 36880 has been marked as a duplicate of this bug. ***

Comment 7

[leger]

Putting on [NEED INFO] so jar can check to see if others see this.  rickg, if 
you are going to try for M16, can you move milestone from M17 back to M16?  
Thanks!

Comment 8

[rickg]

Adjusting milestone accordingly.

Comment 9

[harishd]

*** Bug 36295 has been marked as a duplicate of this bug. ***

Comment 10

[harishd]

I'm taking this one..

Comment 11

[harishd]

*** Bug 36891 has been marked as a duplicate of this bug. ***

Comment 12

[leger]

Putting on a [nsbeta2+] radar for a fix before PR2 ship.

Comment 13

[harishd]

I think 've a fix.  Will check it in on or before Tuesday ( 05/02/00 ).

Comment 14

[rickg]

I think that it's great that we have a fix, and I suspected that it was an easy 
one (see my earlier comments). But the fact that the PDT team keeps changing 
the state to Beta shows a degree of cluelessness that is beyond comprehension.

Comment 15

[Jae Gangemi]

did the fix make it into tuesday's build? or should i expect to see it tomorrow
(wednesday)?

Comment 16

[harishd]

Bug is killed.

Comment 17

[Jan Carpenter]

fixed 
2000-06-28-21-M17 : Win98
2000-06-29-14-M17 : Mac 

Linux build not working, will have to check later.

Comment 18

[John Morrison]

This is fixed, looking at it with the 2000062914 linux build (which is 
running fine for me).

Comment 19

[Jan Carpenter]

Thanks John, marking verified.