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

VERIFIED FIXED in M12

Status

()

Core
DOM: Core & HTML
P2
critical
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Crysgem, Assigned: harishd)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE], URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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
(Reporter)

Updated

19 years ago
Priority: P3 → P1

Updated

19 years ago
Assignee: don → matt
Target Milestone: M7

Comment 1

19 years ago
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.

Updated

19 years ago
Component: Apprunner → JavaScript
QA Contact: leger → desale

Comment 2

19 years ago
Updating QA Contact

Updated

19 years ago
Component: JavaScript → DOM Level 0

Comment 3

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

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 4

19 years ago
works for me on todays build
tested on both win98 and winNT
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 5

19 years ago
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.
(Reporter)

Updated

19 years ago
Summary: Crash on startup → [CRASH] Crash loading http://spaceflight.nasa.gov/

Comment 6

19 years ago
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
(Reporter)

Updated

19 years ago
Blocks: 6089

Updated

19 years ago
Target Milestone: M7 → M8

Comment 7

19 years ago
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?

Updated

19 years ago
Resolution: WORKSFORME → ---

Updated

19 years ago
Assignee: matt → vidur
Status: REOPENED → NEW

Comment 8

19 years ago
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                  }

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME

Comment 9

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

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 10

19 years ago
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

19 years ago
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

19 years ago
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

Updated

19 years ago
Resolution: WORKSFORME → ---
Target Milestone: M8 → M9

Comment 13

19 years ago
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

19 years ago
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.

Updated

19 years ago
Whiteboard: [MAKINGTEST] david.hallowell@ukuug.org

Comment 15

19 years ago
Created attachment 1060 [details]
Mozilla not handling </SCRIPT> tags properly

Updated

19 years ago
OS: Windows 98 → All
Whiteboard: [MAKINGTEST] david.hallowell@ukuug.org → [TESTCASE] Mozilla incorrectly interprets </SCRIPT*> within strings in JavaScript as a </SCRIPT> tag.

Comment 16

19 years ago
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

19 years ago
Created attachment 1078 [details]
Same problem for </style> tags

Updated

19 years ago
Target Milestone: M9 → M10

Comment 18

19 years ago
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....
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...

Updated

19 years ago
Assignee: vidur → rickg
Status: REOPENED → NEW
Summary: [CRASH] Crash loading http://spaceflight.nasa.gov/ → Mozilla incorrectly interprets </SCRIPT*> within strings in JavaScript as a </SCRIPT> tag.
Whiteboard: [TESTCASE] Mozilla incorrectly interprets </SCRIPT*> within strings in JavaScript as a </SCRIPT> tag. → [TESTCASE]

Comment 20

19 years ago
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.
(Assignee)

Updated

19 years ago
Assignee: rickg → harishd
(Assignee)

Comment 21

19 years ago
Assigning this to myself.
(Assignee)

Updated

19 years ago
Priority: P1 → P2
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M10 → M11

Comment 22

19 years ago
moving to m11.  let me know if a fix is close.
(Assignee)

Updated

19 years ago
Target Milestone: M11 → M12
(Assignee)

Comment 23

19 years ago
Let me deal with this in M12.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 24

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

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 25

19 years ago
Tested on 10-09-09. Working fine.

Comment 26

18 years ago
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.
You need to log in before you can comment on or make changes to this bug.