From Bugzilla Helper: User-Agent: Mozilla/4.74 [en] (Win98; U) BuildID: 2000080808 calling eval() in an onLoad handler for the page that sets a frame[x].location="http://xxx' generates an uncaught exception Failure code: -2147467259 nsresult: 0x80004005 (NS_ERROR_FAILURE) Reproducible: Always Steps to Reproduce: 1. Open javascript console. 2. Try above URL. 3. Actual Results: A javascript error happened as illustrated above. The browser did not crash, nor did the eval() code run. Expected Results: Bottom frame of the window should be replaced with the text "This is a blank document." This works in Netscape 4.74.

Comments from IRC: - I'm running the Linux M17 build, and I got no bottom frame and also no error. - someone else running unknown build got a javascript error on line 7 the line with eval() - some else got the same as this bug, again unconfirmed build number.

Browser, not engine. Changing component to DOM Level 0 -

Using Mozilla debug builds 2000-08-09 on WinNT, 2000-08-10 on Linux. Can confirm what has been reported: on both WinNT and Linux, the lower frame comes up blank instead of showing "This is a blank document." On Linux, there are no errors in the debug console or JavaScript console. On WinNT, we get this error in the consoles: JavaScript error: line 0: uncaught exception: [Exception... "Failure" code: "-2147467259" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: http://www.davin.ottawa.on.ca/~matthew/onload/contents.html Line:7 ]

Note: the Web page in question uses a FRAMESET - Note: the lower frame shows "This is a blank document." in both NN4.7 and IE4.7, but each browser reports a JavaScript error !!! In NN4.7 JavaScript Error: http://www.davin.ottawa.on.ca/~matthew/onload/blank.html, line 5: go is not defined. In IE4.7 An error has occurred in the script on this page. Line: 5 Error: Object expected Note that according to the ECMAScript standards, Mozilla JavaScript will not treat errors as leniently as NN4.7 did. Perhaps this is why the text does not display in Mozilla; I will defer to the DOM experts as to what the error is.

Regardless if this is valid behaviour or not, I should not, by writing bad javascript, be able to generate an "uncaught exception", should I? I have created another page at http://www.davin.ottawa.on.ca/~matthew/onload2/ which removes the javascript error, but still does not load the bottom frame correctly.

Writing bad JS will in a lot of cases result in the JS engine throwing exceptions and if you don't explicitely catch those you'll get an error saying "uncaught exception".

I don't see the exception any more, but the page doesn't do what it should do either. Rick, you said you had a similar bug that was due to session history overriding the url we're loading in a case like this, right? I think this could be a dupe of that bug.

Confirmed that using build 2000-09-07-04 Win32 on Win98, the exception is gone. The behaviour is still not correct as noted.

Yes I believe that this is caused by the Frameset-Restoration-State (FRS) code that SH does. Currently, if the parent of a frame is loading, the frame assumes that it is in FRS mode and ignores the URI passed into LoadURI and uses the one in the SHEntry instead. This should *only* be done for the 'initial' URI being loaded. But I believe that it is done for *every* one. So, we ignore the URI provided by .location and use the one supplied by SH. BTW, this is just a guess of what's going on :-) I haven't had time to trace through it in the debugger :-(

It looks like this is yet another dup of bug #48382 *** This bug has been marked as a duplicate of 48382 ***

Verified dupe.