From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; m16) Gecko/20000612 BuildID: 2000061220 browser shut down when try to opening page at http://www.catia.com. The page is optimized for Netscape 4.0 and above and MS IE 4 and above. Reproducible: Always Steps to Reproduce: 1.try to open the page at http://www.catia.pl 2. 3. The page at http://www.catia.com looks bether with built 20000060508, but the built is always stopign when I try to use link defined by javacript (on the left of page).

Since www.catia.pl seems to be a nonexisting host, I assume this is a typo, and you always meant www.catia.com. In M16, I can only see the deadlock caused by clicking on javascript links. This is described in bug 37463 (I saw the well-known stack trace in thread 2). However, the 2000061314-M17 build crashes on www.catia.com with the same stack trace as found in bug 42439: #885 0x4010ee18 in js_Execute () from libmozjs.so #886 0x400f6717 in JS_EvaluateUCScriptForPrincipals () from libmozjs.so #887 0x403d83c1 in nsJSContext::EvaluateString () from libjsdom.so #888 0x40b7329a in NSGetModule () from libraptorhtml.so #889 0x40b7498b in NSGetModule () from libraptorhtml.so #890 0x40b6fc19 in NSGetModule () from libraptorhtml.so #891 0x40de44cd in NSGetModule () from libraptorhtmlpars.so #892 0x40db1b97 in NSGetModule () from libraptorhtmlpars.so #893 0x40de3ab9 in NSGetModule () from libraptorhtmlpars.so #894 0x40db15ee in NSGetModule () from libraptorhtmlpars.so #895 0x40db111a in NSGetModule () from libraptorhtmlpars.so #896 0x40db0eb4 in NSGetModule () from libraptorhtmlpars.so #897 0x40dba5d3 in NSGetModule () from libraptorhtmlpars.so #898 0x40dba415 in NSGetModule () from libraptorhtmlpars.so #899 0x40db9edc in NSGetModule () from libraptorhtmlpars.so #900 0x40b7c696 in NSGetModule () from libraptorhtml.so #901 0x40b7c743 in NSGetModule () from libraptorhtml.so #902 0x40417897 in NS_NewScriptHTMLDivElement () from libjsdom.so #903 0x4010ea5f in js_Invoke () from libmozjs.so #904 0x40115352 in js_Interpret () from libmozjs.so #905 0x4010ee18 in js_Execute () If someone can locate the problem in the page source, we could probably resolve it as a duplicate of bug 42439.

The www.catia.com page is made of frames. By reducing that page, I came to the conclusion that the crash was caused by the content of one the frame, which comes from www.catia.com/html/action.htm. I'm attaching a simplified testcase of action.htm below. The problem seems to come from a <SCRIPT> tag being added (by document.write()) inside another <SCRIPT> tag, like in bug #42439.

*** This bug has been marked as a duplicate of 42439 ***

www.catia.com crashes on Linux 2000-09-17-06. Reopening.

Using Mozilla tip build 2000-09-13 12PM Pacific Time on Linux. Was able to reproduce crash by loading http://www.catia.com The stack trace shows calls like this at the top: (CRASH) ----------------------------- --> libnecko.so --> libxpcom.so --> libwidget_gtk.so etc. etc. Will attach full trace below. NOTE: I was not able to reproduce the crash with every Linux nightly build I have: 2000082313 --> OK 2000090508 --> OK 2000091208 --> CRASH !!! NOTE: I have not reproduced the crash on WinNT...

Note: a JavaScript error occurs whenever you load http://www.catia.com Error: doc is not defined Source File: http://www.catia.com/js/heval2.js Line: 17 This is because the Web page uses insufficient browser sniffing. It is able to detect NN4.x or IE4, but does not detect Mozilla: (Here is the source for http://www.catia.com/js/heval2.js): function Heval() { NS4 = (document.layers) ? 1 : 0; IE4 = (document.all) ? 1 : 0; if (NS4) { Hwindow=window.innerHeight; Hdoc=self.document.height; doc="document"; styl="" } if (IE4) { Hwindow=document.body.offsetHeight; Hdoc=document.body.scrollHeight; doc="document.all"; styl=".style" } toplayer=eval(doc+'["backtop"]'+styl); <<<<<<<<<<<<<<<< ERROR OCCURS HERE yascroll=(Hwindow<Hdoc) ? 1 : 0; if (yascroll) {toplayer.visibility="visible";} else {toplayer.visibility ="hidden";} onresize = Heval; } No JS Engine issues are apparent either here, or in the stack trace. Reassigning to Networking for further triage -

Note almost the same stack trace in bug 52949 (2000-09-18 13:59) ...

*** This bug has been marked as a duplicate of 52397 ***

verif. dup