Closed Bug 15427 Opened 21 years ago Closed 20 years ago

JavaScript seems to cause crash


(Core :: JavaScript Engine, defect, P3)

Windows 95





(Reporter: ssym, Assigned: mike+mozilla)




(Keywords: crash)


Clicking on a link that leasds to JavaScript causes a browser crash.  The
JavaScript causing the crash works perfectly in both NS 4.x and IE 4 & 5.


1. Go to
2. Click on the "Student Life" link, then click on the "Dean of Students" link.
3. Wait for everything to load, then click on the "Residences" link.
4. Now you're at the problem place .... wait for stuff to load, click on any
link from the left-hand side frame.

Or you can skip steps 1-3 and go directly to the address at step 4, and click on
a link, I think.


Apprunner crashed.  The "Details..." box gives the following:

APPRUNNER caused an invalid page fault in
module JS3250.DLL at 0137:6081a8cb.
EAX=00000000 CS=0137 EIP=6081a8cb EFLGS=00010246
EBX=00000000 SS=013f ESP=0063f4a4 EBP=0063f4c4
ECX=0063f4c0 DS=013f ESI=6081a8bd FS=2b37
EDX=00000004 ES=013f EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 40 34 eb 03 8b 40 28 89 01 c3 8b 44 24 08 8b
Stack dump:
60061b8b 00000000 0063f4c0 80000000 80000000 00000000 60063200 00000000 0063f4f4
600619c0 007e77f0 00000000 0157ef00 0157ef00 ff8c4d10 11d33194


Ummm, maybe it should actually load the relevant page?


Using build 1999091713, using Windows 95 ver 4.00.1111.
Closed: 21 years ago
Resolution: --- → WORKSFORME
hi, ssym.  i just checked this out with M10, and it worked for me.  can you try
to reproduce this with a more recent build?  if you are able to reproduce the
problem with a more recent build, please re-open the bug.  thank you.
No, still screws up.  The address is, and
there seems to be another problem as well.  When viewed in IE or Netscape, the
JavaScripted links on that page were lined up nicely under each other, now some
of them are side-by-side??!  Strange.  And this didn't happen in previous
builds, IIRC.

Click on the "Sports Admin" link, wait for the page to load, click on the
"Residences" link from the left-hand side buttons.  The browser STILL crashes,
and I am using a later build ..... build 1999101312 to be exact.  Further along
than M10, therefore.  The "Details" tab brings up:

MOZILLA caused an invalid page fault in
module GKWEB.DLL at 0137:608b2564.
EAX=00000000 CS=0137 EIP=608b2564 EFLGS=00010246
EBX=00000000 SS=013f ESP=0063f2fc EBP=0063f378
ECX=012d6788 DS=013f ESI=00000000 FS=0f9f
EDX=816f9820 ES=013f EDI=01334cd0 GS=0000
Bytes at CS:EIP:
8b 08 56 50 ff 51 2c 8d 4d fc 8b f0 e8 35 52 00
Stack dump:
ffffffff 00000000 01334cd0 012d6720 01334cd0 00000009 7800cc87 608ba514 01334cd0
00000000 01334cc0 816ff558 0000001c 0063fbb0 7800ef06 7802e248

.......thus I have reopened this one.  If it makes a difference, I'm using a
proxy server .... don't know if that has any relevance.
I tested the above with M10 and 1999102109 on Linux (RH6.0). No crash, but
clicking on the Residences link just yields a gray frame on the left where
the menu was. The menu uses JavaScript URLs, though, such as:


so this behavior might be explained by the venerable bug #1646.
Resolution: WORKSFORME → ---
Clearing WORKSFORME resolution due to reopen of this bug.
I'm testing this on M11 (Build: 1999111520) on Windows NT and it WORKSFORME.
I tried both suggested steps, and pages displayed 100% accurately. Clicking on
the Residences link (or any button) displays a temporary white page with a
local url, which is replaced a second later with the side frame with buttons.
Then the main page is loaded with the appropriate section.
QA Contact: cbegle → rginda
Setting QA Contact.
This worksforme on todays linux build, although I'm not going through a proxy
ssym, is this still crashing for you?
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
 no longer has buttons on the right with javascript links. However might be a related crash(based on the debugging
info) when you click on the article "Foreign Tongues" I get a crash in GKWEB.DLL
on winNT build 2000040308.
Severity: normal → critical
I encountered a JavaScript freeze/crash today and did a Bugzilla search to see
if I could find any previously filed reports. This one looked like the closest
match. I was unable to reproduce the crashes at or but I have a new test case that shows the crash and can be
reproduced every time.

Go to (ironically, this is a JavaScript/DHTML
tutorial page). Dismiss the 'Alert: You need NS or IE 4.0' dialog and scroll to
the bottom of the screen. You will see a section labeled "DynAPI Widgets" with a
numbered list of things like "Scrollbars", "ButtonImage", "Radio Buttons", etc.
You can use any of these links to reproduce the crash, but I used the checkbox
one at:

Scroll down to the bottom of the page and you will see a line that reads:

"Example: checkbox1.html [source] - for a checkbox example."

The "checkbox1.html" and "[source]" text are both hyperlinked. If you float the
mouse over the top of the "checkbox1.html" link you will see in the status bar
that this links to:


(FYI: The 'viewExample' function is not implemented on this page. If you view
the source to this page, at the top the guy imports about 4 other .js files. One
of those probably contains the implementation. I did not try to track down the
exact file.)

Click on the "checkbox1.html" link. Mozilla locks up hard. Doesn't repaint,
doesn't respond to mouse/kbd events, etc. The last thing Moz does before it dies
is print a line in the shell window that reads:

   Error loading URL

I am using a nightly build: 2000050908, PC, Linux.

I tried doing this in Netscape 4.72 and it works correctly; executes the
JavaScript and loads the page in the same browser window.

Hope this helps.
Just tried this bug with M15, Mac OS 9.0.4, MRJ 2.2, carbon libs 1.0.4.

Mozilla didn't crash.  I *did* get an alert box on URL , but the iMac DV I'm using went
on its merry way after I closed the alert box.

Confirmed. Using the Linux M15 build (Build ID: 2000041805) I just tried
clicking the checkbox1.html link at the bottom of and it displayed just fine.

Looks like this is a regression bug.
The recent freeze/lockup is a regression between 5/5 and 5/6, and has been 
reported in bug 37463:
  lockup/freeze upon javascript:window.location="";
I have verified that the stack trace of thread 2 is the same,
using build 2000051308 on PC/Linux. I suggest to discussthe recent regression
there and leave this bug for the originally reported issues. 
Ten-four. Ill add the test case to bug 37463 to see if that

helps. I just wanted to make sure that this was being reported somewhere and I

wasn't sure which was the right bug to attach this to, so I used this one. I'll

use 37463 from now on.

what is the originally reported issue.  I can't find the link that is supposed 
to crash here?
[SPAM] Marking milestone 'future' as part of nsbeta3 triage.
Target Milestone: --- → Future
Setting default QA contact -
QA Contact: rginda → pschwartau
Using: Mozilla binaries 2000093009 on WinNT, 2000092909 on Linux.

As mentioned at 2000-04-03 18:36, "The URL 
no longer has buttons on the right with javascript links." So we can no longer 
use this URL to check the bug.

Also, no longer crashing or locking up at:

2. Checkbox link at bottom of

Resolving WORKSFORME -
Closed: 21 years ago20 years ago
Resolution: --- → WORKSFORME
Marking Verified -
You need to log in before you can comment on or make changes to this bug.