7590 - Mozilla incorrectly interprets </SCRIPT*> within strings in JavaScript as a </SCRIPT> tag.

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Crysgem]

The wending code of Apprunner (Build ID 1999060108) is not equal to this
JavaScript-employing page.

0) Execute Apprunner from the command-line with the above URL.
1) Observe the beast nobly attempt to display the contents for a moment before
crashing.

This criticality has been tested extensively on this computer, at the least - is
reproducible.

Some broken runes:

APPRUNNER caused an invalid page fault in
module JSDOM.DLL at 023f:00cc6a0a.
Registers:
EAX=00000000 CS=023f EIP=00cc6a0a EFLGS=00010282
EBX=00000000 SS=0247 ESP=0076f35c EBP=0076f364
ECX=00c0ca20 DS=0247 ESI=fffffff1 FS=0fb7
EDX=00c0ca24 ES=0247 EDI=02713920 GS=0000
Bytes at CS:EIP:
8b 06 83 65 08 00 8d 4d 08 51 68 e8 89 cf 00 56
Stack dump:
00a44320 00c0ca20 0076f3c8 00cd8daa fffffff1 00a45100 0076f50c 0076f50c 00000030
00905100 0076f3c4 0050b2ac 00c5faa0 00000058 00905100 004fb837

PPRUNNER caused an invalid page fault in
module JSDOM.DLL at 023f:00cc6a0a.
Registers:
EAX=00000000 CS=023f EIP=00cc6a0a EFLGS=00010282
EBX=00000000 SS=0247 ESP=0076f35c EBP=0076f364
ECX=00c24100 DS=0247 ESI=fffffff1 FS=0f37
EDX=00c24104 ES=0247 EDI=00876490 GS=0000
Bytes at CS:EIP:
8b 06 83 65 08 00 8d 4d 08 51 68 e8 89 cf 00 56
Stack dump:
00a40d70 00c24100 0076f3c8 00cd8daa fffffff1 00a40d90 0076f50c 0076f50c 00000030
00905100 0076f3c4 0050b2ac 00c094d0 00000058 00905100 004fb837

Comment 1

[don]

Yep, that crashes allright, and somewhere in the Javascript DOM for me too.  But
only when invoked from the command line.  If you launch apprunner and then go to
the URL it doesn't crash, but it still doesn't really load the page because of
some weird server problem.  And the page loads OK from the command line in
viewer.

Matt, can you check this out and see who's bug this really is, 'cause I doubt
very much whether it's an XPApps-specific problem.

Comment 2

[leger]

Updating QA Contact

Comment 3

[leger]

Looks like a DOM problem.  Please change back tro Javascript Engine component if
this is indeed JS.

Comment 4

[matt]

works for me on todays build
tested on both win98 and winNT

Comment 5

[Crysgem]

In response to matt@netscape's solipsism - the Apprunner of June 8 (Build ID
1999060708) yet crashes on the page, whether instructed to load at execution or
accessed from the Address field. Well, so in my universe.

Comment 6

[Crysgem]

From 1999060708 build:

APPRUNNER caused an invalid page fault in
module JSDOM.DLL at 023f:00cc6a38.
Registers:
EAX=00000000 CS=023f EIP=00cc6a38 EFLGS=00010282
EBX=00000000 SS=0247 ESP=0076f338 EBP=0076f340
ECX=02b1b990 DS=0247 ESI=fffffff1 FS=0fb7
EDX=02b1b994 ES=0247 EDI=02704350 GS=0000
Bytes at CS:EIP:
8b 06 83 65 08 00 8d 4d 08 51 68 b8 89 cf 00 56
Stack dump:
00a77150 02b1b990 0076f3a4 00cd8ed7 fffffff1 00a78860 0076f4e8 0076f4e8 00000030
00922c80 0076f3a0 0050b1de 00a99438 00000058 00922c80 004fb730

Comment 7

[don]

Move this to M8.  I know it's a crash, but we can't reproduce this behavior
consistently enough to fix it yet.

Matt, should we re-assign this to one of the DOM folks?

Comment 8

[chris hofmann]

looks like it might be vidur  I just crashed m7 with this stack
when visiting the page on win95

 Call Stack:    (Signature = nsJSUtils::nsConvertObjectToJSVal 5908f1fe)

  nsJSUtils::nsConvertObjectToJSVal
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSUtils.cpp, line 133]
  GetHTMLLayerElementProperty
[d:\builds\seamonkey\mozilla\dom\src\html\nsJSHTMLLayerElement.cpp, line 211]
  js_GetProperty
[d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 1695]
  js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2164]
  js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676]
  js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2207]
  js_Execute
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 822]
  JS_EvaluateUCScriptForPrincipals
[d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2509]
  nsJSContext::EvaluateString
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 140]
  HTMLContentSink::EvaluateScript
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 2834]
  HTMLContentSink::ProcessSCRIPTTag
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 2969]
  HTMLContentSink::AddLeaf
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 1955]
  CNavDTD::AddLeaf
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 2774]
  CNavDTD::HandleScriptToken
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1767]
  CNavDTD::OpenContainer
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 2596]
  CNavDTD::HandleDefaultStartToken
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1096]
  CNavDTD::HandleStartToken
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1413]
  NavDispatchTokenHandler
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 244]
  CTokenHandler::operator()
[d:\builds\seamonkey\mozilla\htmlparser\src\nsTokenHandler.cpp, line 83]
  CNavDTD::HandleToken
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 692]
  CNavDTD::BuildModel
d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 526]
  nsParser::BuildModel
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 903]
  nsParser::ResumeParse
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 852]
  nsParser::OnDataAvailable
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1073]
  nsDocumentBindInfo::OnDataAvailable
[d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 1563]
  OnDataAvailableProxyEvent::HandleEvent
[d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 634]
  StreamListenerProxyEvent::HandlePLEvent

[d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 474]
  PL_HandleEvent
                                         [plevent.c, line 492]
  PL_ProcessPendingEvents
                                         [plevent.c, line 453]
  _md_EventReceiverProc
                                         [plevent.c, line 881]
  KERNEL32.DLL + 0x3663 (0xbff73663)
  KERNEL32.DLL + 0x22894 (0xbff92894)
  0x00768c0c

126 vidur     1.2  nsJSUtils::nsConvertObjectToJSVal(nsISupports* aSupports,
127                                                  JSContext* aContext,
128                                                  jsval* aReturn)
129 vidur     1.1  {
130                  // get the js object\n"
131                  if (aSupports != nsnull) {
132                    nsIScriptObjectOwner *owner = nsnull;
>>>>> 133                    if (NS_OK ==
aSupports->QueryInterface(kIScriptObjectOwnerIID, (void**)&owner)) {
134                      JSObject *object = nsnull;
135                      nsIScriptContext *script_cx = (nsIScriptContext
*)JS_GetContextPrivate(aContext);
136                      if (NS_OK == owner->GetScriptObject(script_cx,
(void**)&object)) {
137 vidur     1.2          // set the return value
138                        *aReturn = OBJECT_TO_JSVAL(object);
139 vidur     1.1        }
140                      NS_RELEASE(owner);
141                    }
142                    NS_RELEASE(aSupports);
143                  }

Comment 9

[vidur (gone)]

document.layers support was temporarily and incorrectly turned on. The page
doesn't crash on a 7/2 build.

Comment 10

[Prashant Desale]

I tried it with 07-02 build and application is crashing on visiting the URL
mentioned above. I tested it on Win-95, and it crashes. Reopening bug.

Comment 11

[vidur (gone)]

Again, it doesn't crash for me. I suspect it might have something to do with the
fact that there is an applet on the page. Since I don't have the OJI plugin
installed, this fails silently for me. Is it possible that the OJI plugin is
installed incorrectly on your build and you're crashing while bringing up the
applet?

Comment 12

[Prashant Desale]

Vidur, Here is a stack trace for this one. This might help you.

Incident ID: 10849958

Call Stack:    (Signature = nsJSUtils::nsConvertObjectToJSVal 41c31002)

nsJSUtils::nsConvertObjectToJSVal
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSUtils.cpp, line 133]
GetHTMLLayerElementProperty
[d:\builds\seamonkey\mozilla\dom\src\html\nsJSHTMLLayerElement.cpp, line 211]
js_GetProperty
[d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 1701]
js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2175]
js_Invoke
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 676]
js_Interpret
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2218]
js_Execute
[d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 833]
JS_EvaluateUCScriptForPrincipals
[d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 2586]
nsJSContext::EvaluateString
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 140]
HTMLContentSink::EvaluateScript
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 2860]
HTMLContentSink::ProcessSCRIPTTag
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 2984]
HTMLContentSink::AddLeaf
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 1967]
RAPTORHTMLPARS.DLL + 0x735f
(0x6090735f)
RAPTORHTMLPARS.DLL + 0x66a3
(0x609066a3)
RAPTORHTMLPARS.DLL + 0x7049
(0x60907049)
RAPTORHTMLPARS.DLL + 0x5a05
(0x60905a05)
RAPTORHTMLPARS.DLL + 0x61a8
(0x609061a8)
RAPTORHTMLPARS.DLL + 0x50a3
(0x609050a3)
RAPTORHTMLPARS.DLL + 0xcf07
(0x6090cf07)
RAPTORHTMLPARS.DLL + 0x582a
(0x6090582a)
RAPTORHTMLPARS.DLL + 0x54fd
(0x609054fd)
RAPTORHTMLPARS.DLL + 0xbac0
(0x6090bac0)
RAPTORHTMLPARS.DLL + 0xba35
(0x6090ba35)
RAPTORHTMLPARS.DLL + 0xb480
(0x6090b480)
HTMLContentSink::ResumeParsing
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 2774]
nsDoneLoadingScript
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp,
line 2891]
RAPTORWEB.DLL + 0x29fe (0x609629fe)
OnStopRequestProxyEvent::HandleEvent
[d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 594]
StreamListenerProxyEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\network\module\nsNetThread.cpp, line 474]
PLDS3.DLL + 0x18ee (0x608c18ee)
PLDS3.DLL + 0x186a (0x608c186a)
PLDS3.DLL + 0x1b18 (0x608c1b18)
KERNEL32.DLL + 0x35d9 (0xbff735d9)
KERNEL32.DLL + 0x2222f (0xbff9222f)
0x00638c20



 Registers:
 EAX: 00000000 EBX: 006ec618 ECX: 0378bcf0 EDX: 0378bcf4
 ESI: fffffff1 EDI: 00000000 ESP: 0063f2a4 EBP: 0063f2ac
 EIP: 607073abcf pf af zf SF of IF df nt RF vm   IOPL: 0

 CS: 016f DS: 0177 SS: 0177 ES: 0177 FS: 0fcf GS: 0000


Operating System:  Windows 95 4.0 build 67306684

Service Pack:   C

Processor:  Pentium

Processor Speed:  Not Available

Physical Memory:  128.0 MB

MEMORYSTATUS Structure:

                     Available     Total
Physical Memory:        1.0 MB      128.0 MB
Page File:           1096.3 MB     1114.4 MB
Virtual Memory:      1973.1 MB     2044.0 MB

Comment 13

[vidur (gone)]

Well, the stack trace vindicates the OJI stuff. I'm still not seeing the crash
on the 7/6 build. Moving it off to M9 for more investigation.

Comment 14

[Crysgem]

The M8 release notes
(http://www.mozilla.org/projects/seamonkey/release-notes/m8.html) claim that DOM
Level 0 functionality is "Done.".
Not so.
Broken runes from M8:

APPRUNNER caused an invalid page fault in
module NETLIB.DLL at 023f:607499ef.
Registers:
EAX=00a63cfd CS=023f EIP=607499ef EFLGS=00010206
EBX=602a0711 SS=0247 ESP=0063f974 EBP=0063f990
ECX=00a84c80 DS=0247 ESI=00a868b4 FS=10b7
EDX=014c7960 ES=0247 EDI=00a868b0 GS=0000
Bytes at CS:EIP:
11 aa 0c 00 80 5f 8a 7a c4 40 6f 6b 10 9e d7 d2
Stack dump:
00a63cb0 602a481c 00a887e0 0063f98c 00000002 00a868b4 00a63cb0 0063f9bc 602a47db
00000001 00a86d30 00000000 0063fa40 00000000 00000000 00000000

JSDOM.DLL and an <unknown> module also fall.

Comment 15

[David Hallowell]

Attachment: Mozilla not handling </SCRIPT> tags properly

Comment 16

[David Hallowell]

Tested on:
Windows 98 (M8)
Windows 95 w/IE4 desktop (build: 1999073011)
Linux 2.2 (RedHat 6.0) (build: 19973008)
Problem occurs on all the above platforms.

The problem appears to be caused by Mozilla misinterpretating an occurance of
</SCRIPT> within a JavaScript string. For example the following line of code on
the NASA site caused problems:
document.write('<script language="javascript"
src="dayfacts/'+dateVar+'.js"></SCRIPT>')
Mozilla was interpreting the </SCRIPT> in the string as the end of the
JavaScript code. The problem also occurs when what appears like a closing tag
beginning with script (e.g. </SCRIPTKIDDIE>) appears in a string.

It appears that Mozilla is not checking to see if what appears to be a tag
indicating the end of the JavaScript code is actually contained within a string,
it is also not actually checking the entire contents of the tag. If it gets as
far as </SCRIPT it assumes a </SCRIPT> tag. This also occurs outside of strings
for example:
<HTML>
<BODY>
<SCRIPT LANGUAGE="JavaScript">
	document.write('Test');
</SCRIPTERROR>
	document.write('Test2');
</SCRIPT>
</BODY>
</HTML>

Would produce the following output in Mozilla:
Test document.write('Test2');
Indicating that the </SCRIPTERROR> tag was taken by mozilla to be the end of the
script and document.write('Test2'); was just plain text.

The expected result was that which occured in Netscape 4.6 and IE 4 which was to
report a JavaScript error because of the </SCRIPTERROR> is invalid JavaScript.
Please note that commenting out the </SCRIPTERROR> tag made the code work
properly in Netscape 4.6 and IE4 but didn't make a difference in Mozilla.

Comment 17

[David Hallowell]

Attachment: Same problem for </style> tags

Comment 18

[Chris Waterson]

This appears to be a generic problem with the HTML parser: 4.x and IE must be
(?) more resilient with respect to '<' and '>' contained inside a script tag.
Can we roll this logic forward?

In the XML parser, we've defined this problem away by requiring entities
(e.g., "&lt;" instead of "<"), enclosure within a CDATA section, or a separate
file.

Seems like this is something that rickg should be investigating, not vidur....

Comment 19

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The behavior is correct, though.  An element with CDATA content is ended by the
first occurence of "</".  If what follows isn't the end tag for the element, the
document is invalid.  Fixing this should be quirks-mode only.  I think there may
be another bug on it somewhere...

Comment 20

[vidur (gone)]

1) I finally started seeing the crash. It was the result of trying to get the
address of a pointer when I just needed the pointer itself. Since the result
is non deterministic, I can understand why it didn't crash for me earlier. Fix
checked in on 9/14/1999.
2) I'm not too concerned about the layers aspects of the page since we've made a
decision to not support layers in 5.0.
3) The SCRIPT issue is a valid one, though I seem to remember resolving this
with RickG many months ago.

Changing the subject and passing along to RickG to get his opinion.

Comment 21

[harishd]

Assigning this to myself.

Comment 22

[chris hofmann]

moving to m11.  let me know if a fix is close.

Comment 23

[harishd]

Let me deal with this in M12.

Comment 24

[harishd]

This is FIXED.  As David mentioned, this is quirks-mode-only fix.

Comment 25

[Prashant Desale]

Tested on 10-09-09. Working fine.

Comment 26

[Peter 'Rufus' Nelson]

the first attachment (</script>) still doesn't work in M14, and I've actually
noticed it on a number of sites.  An other note, bug 18324, bug 21944, and bug
26857 are all exact duplicates of this one.