BuildID: 2000101014 (M18) Accessing to IFRAME content crashes Moz. More precisely, it works the first time, but the 2nd Mozilla crashes Reproducible: Sometimes Steps to Reproduce: put an IFrame in your document <iframe id="myIFrame" src="fill.htm"></iframe> try both (example: reads document.title) alert(window.frames.myIFrame.document.title); alert(document.getElementById("myIFrame").contentDocument.title); they both do work the first time they are called, but the 2nd Mozilla crashes :- (

sorry for the mess, but the testcase needs the fill.htm file to fill the IFRAME. I uploaded that too but it seems thay are not in the same directory, can someone fix the problem? thanks. Federico

er, that should have been "fill.htm" In any case, I do not see a crash with linux trunk build 2000110521. Federico, could you try a recent nightly and see if you can reproduce the problem? Try to do it with a Talkback-enabled build and submit the Talkback incident ID with you comments if you crash so that this bug can be correlated with the Talkback data....

hello Boris, I just tested the testcase :-) and it now crashed at the first click. for me is a big pain downloading a talkback build, but I just started.

WFM for me with win2k and trunk build 2000110420

This works fine on the netscape branch but on the trunk I see weird problems, I don't even get the alert window to show up when I click on one of the links so I'm a bit confused about what could be causing this. If I reload the page after I've clicked on one of the links I crash somewhere in focus code... weird... I'm guessing there's a modality problem in current trunk builds on linux.

I don't know what to say, I tried sometimes the testcase with 2000110604 with talkback. sometimes it happens at first, sometimes after more clicks, but Mozilla still crashes. to be more precise, it just hangs up without responding to any avent, the "Netscape Quality Feedback Agent" doesn't even appear and I have to kill the process with task Manager. I'm running MS Windows 2000 Professional 5.00.2195, can't remember if with some service pack. Federico

using Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 with win98.

Aha! So this is not really a crash, it's a lockup. This is probably due to the bugs with modal windows not always showing up and locking up the system then, there's a couple of bugs on that but I don't have em handy so I'll leave this one open untill I find those bugs and check if this is possibly a dup, could even be a dup of 58404...

To my testcase! Using Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/20001126 on Win95 and Win98 I don't think oit have to do with bug 58404 because this bug is permanent and not unregular but it seem to make a memory leak (because mozilla slow down). It had also not realy to do with bug 52334 and 60960 but I don't now if they depend on this bug. The onload problem can have to do something with the Bug 57636. OK! Let me know if you need more information.

Alexander, are you still able to reproduce this?

OK! Today I using: Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/2000121404 (realy m18 not m0.6 ??) OK, i get some new error's ... for them I must create a 2 new tescase (because it is the think, that I can't change websites from other servers (secure reasons)!). The first testcase is the blind blue frame inside and the second will the new tester. I think the bug report to the JavaScript Console aren't clear! (The first is a not filled error with the right line and the filename and the second error is the uncought exception [access denied bla bla] but with no source file and line number 0). "document.getElementById('iframeId').contentDocument.body" is already undefined and rise an Error on JavaScript Console (if it is undefined, why rise the error??) ok ... so far ... the two new testcases follow in some minutes.

Last sentencres for that! *fine* it work's well, if you have write it well! Please use my old testcase to change some little Error message on the JavaScript Console. Because alert(document.getElementById('iframeId').contentDocument.body) must raise also an access denied error like document.getElementById('iframeId').contentDocument.documentElement and not only the 0 Error! And on body you get back undefined on documentElement not! I think it must the same on both. But else it is fine. The onload in the iframe does not fire ... but I don't know if hge/she/it can fire that :-) ! ok, I will go to bug bug 52334 to lock there for changes an eventuall repair's of the testcase! *worksforme

Ok, now I'm confused, I don't know what's wrong here, all I know is that whatever I do with the testcases in this bug I can not reproduce a crash, marking WORKSFORME. If there's a problem with something going wrong in the testcase then please open a *new* bug on that, only reopen this if mozilla *crashes* when accessing the testcases...

marking verified using the 2000122904 nightly build on win2k. i can't reproduce a crash with any of the testcases.