Closed Bug 219504 Opened 21 years ago Closed 20 years ago

Consumption of script element ends at wrong end-tag

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rr_mozilla, Assigned: mrbkap)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(2 files)

Testcase
222 bytes, text/html
Details
patch v1
3.00 KB, patch
bzbarsky
: review+
rbs
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827

Under IE page is rendered as a compact orderly placement. Under Mozilla page
elements are rendered more or less one after another vertically starting from
top to bottom, each taking up a separate horizontal area. Leaves a lot of white
space and loses generel page organization of left sidebar with body text to the
right.

Reproducible: Always

Steps to Reproduce:
1. type in URL
2. view poorly spaced elements in long vertical presentation
3.

Actual Results:  
Page with bad layout: sidebar elements, followed vertically by body text and pix
followed by more sidebar elements

Expected Results:  
Lay out with left side bar at left and body text at right of sidebar
The page doesn´t validate. It is a frameset with one frame only, and validating
the frameset gives 3 errors, after manually specifying a language definition.
Validating the frame gives more than 50 errors.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.isimtouch.com%2Fproducts%2Flv%2F&charset=%28detect+automatically%29&doctype=HTML+4.01+Transitional&ss=1

I´m no Markup specialist, but I know that mozilla doesn´t like XML-style endtags
in HTML, there are some />. The website also lacks the </html> tag at the end,
has a </form> tag somewhere whithout a preceding <form> tag.

I don´t know what Mozilla doesn´t like over there, but there is a lot.
Speculating on what problems with the page might be causing the problems isn't
really very useful.  It is useful to know why the differences occur, and that
usually requires either a minimized testcase or examination of the page close
enough to tell that a clearly known problem is present on the page.

Mozilla just ignores end tags that don't have matching start tags.  XML-style
empty tags could be more of a problem, but why would IE/Windows behave differently?
------------------------------------------------------------
<script language="JavaScript"><!--
.
.
.
</script>
</head>

<body ... >
.
.
.
<script lang="javascript"> ... </script>
------------------------------------------------------------

The page seem to render OK (I'm currently on a very old mac classic build) if
you remove the "<!--" or add an "//-->" before the last </script>. 
-> Parser

I think this is invalid, there is no --> so we will hit end-of-document and then
fall back to the last </script>

The algorithm is documented here:
http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsHTMLTokens.cpp#561
Assignee: table → harishd
Component: Layout: Tables → Parser
Keywords: testcase
OS: Windows XP → All
Hardware: PC → All
Attached file Testcase — 

    
    

    
  
Why are we doing comment parsing inside a <script> tag to start with?  That
seems wrong....

    
    

    
  
This is fallout from the fix for bug 26652. In essence, we use people's habit of
wrapping the contents of their script tags in <!-- ... --> to help us detect
improperly escaped "</script>", e.g., document.write("</script>"). Personally, I
find that rather egregiously dumb, and I'd rather fix this bug, but I don't have
a sense of what the real-world proportions are. (26652 has only one dupe, but it
was fixed in about 2 months, and in early 2000.)

    
    

    
  
Confirming this (in my quest to clear out unconfirmed HTML: Parser bugs). It's
worth noting that we only consider the comments in Quirks mode. The fix would be
to rip out most of the guts of CTextToken::ConsumeUntil and make it actually
follow the spec (up to a point).
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
I'm playing around with IE's parsing of this sort of stuff, and it seems like
they also look for the close comment. However, in the case where that close
comment never comes, I think that instead of taking the *last* occurance of
</script>, they take the first.

Therefore, in the testcase, IE sees that the <script> tag starts with a comment
and looks for the end tag preceeded by the close comment. However, one never
comes (it hits EOF). In this situation, we use the last </script> tag, thus
eating all of the content in between. IE, on the other hand uses the first
</script tag it saw (up at the beginning), letting most of the content be parsed
as HTML.

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v1
        — 
          — Splinter Review
      

    


  
This patch makes us imitate IE's behavior.
Assignee: harishd → mrbkap
Status: NEW → ASSIGNED

    
    

    
  
Comment on attachment 158658 [details] [diff] [review]
patch v1

bz, looking for r=. The patch is fairly straightforward.

        Attachment #158658 -
        Flags: review?(bzbarsky)

    
    

    
  
Comment on attachment 158658 [details] [diff] [review]
patch v1

r=bzbarsky.  rbs, would you give this a once-over too, just in case?  This code
is hairy.  :(

        Attachment #158658 -
        Flags: superreview?(rbs)

        Attachment #158658 -
        Flags: review?(bzbarsky)

        Attachment #158658 -
        Flags: review+

    
    

    
  
Comment on attachment 158658 [details] [diff] [review]
patch v1

sr=rbs

Took several readings to grasp that dreaded code. Patch looks fine (and should
there be any problem, it can only bite tag soups that deserve to be bitten
anyway).

        Attachment #158658 -
        Flags: superreview?(rbs) → superreview+

    
    

    
  
Checked in for 1.8a4.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

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

    
    

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

    
    

    
  
While I'm spamming this bug with DUPEs, changing the summary to reflect the bug
solved here. This bug really should have been a dupe of one of the other two.
Summary: page obects placement  badly rendered compared to IE 5+ → Consumption of script element ends at wrong end-tag

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: