Closed Bug 15427 Opened 25 years ago Closed 24 years ago

JavaScript seems to cause crash

Categories

(Core :: JavaScript Engine, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: ssym, Assigned: mike+mozilla)

References

()

Details

(Keywords: crash)

DESCRIPTION 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. STEPS TO REPRODUCE 1. Go to http://www.ru.ac.za. 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. ACTUAL RESULTS Apprunner crashed. The "Details..." box gives the following: APPRUNNER caused an invalid page fault in module JS3250.DLL at 0137:6081a8cb. Registers: 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 EXPECTED RESULTS Ummm, maybe it should actually load the relevant page? BUILD DATE & PLATFORM Using build 1999091713, using Windows 95 ver 4.00.1111.
Status: NEW → RESOLVED
Closed: 25 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.
Status: RESOLVED → REOPENED
No, still screws up. The address is http://www.rhodes.ac.za/services/dos, 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. Registers: 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: javascript:parent.location='../residences/main.htm' 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 here. ssym, is this still crashing for you?
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
The URL http://www.rhodes.ac.za/services/dos no longer has buttons on the right with javascript links. However http://www.maximonline.com/ 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 www.rhodes.ac.za/services/dos or www.maximonline.com but I have a new test case that shows the crash and can be reproduced every time. Go to http://dansteinman.com/dynduo/ (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: http://dansteinman.com/dynduo/en/checkbox.html 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: javascript:viewExample('checkbox1.html',1) (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 http://dansteinman.com/dynduo/en/checkbox.html 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 http://dansteinman.com/dynduo/en/checkbox.html , 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 http://dansteinman.com/dynduo/en/checkbox.html 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="http://www.mozilla.org"; 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 dansteinman.com 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 http://www.rhodes.ac.za/services/dos 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: 1. http://www.maximonline.com/ 2. Checkbox link at bottom of http://dansteinman.com/dynduo/en/checkbox.html Resolving WORKSFORME -
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.