This bug is a direct spinoff of bug 6234, but there are a number of other bugs addressing this issue. I'll try to find them later. The problem is where the contents of a frame are not displayed, but instead you see some (possibly updating) contents of other frames. This happens in the lower left frame of http://www.eage.nl/student , and it also happens in apprunner while apprunner is loading, which is why this problem is so serious. I've isolated the problem in http://www.eage.nl/student/ down to the combination of SCROLLING="NO" and some CSS. It's hard to isolate, because the problem becomes milder on less complex pages. I'll try to attach a test case soon once I get it reasonably simple. I do have a test case that is a pretty clear demo of the problem, but I want it simpler!

I just realized there was a problem with my simplification - one of the style elements was unclosed. However, this demo still shows very interesting behavior. One frame appears in the window where a blank document should be. I'll try to resimplify from scratch, but the frameset document coming next is not the simplification of the originally described bug - but it shows an even simpler case of how what should be in one frame appears again in another (could this be what makes frames so slow?).

Actually, this depends on the body element being empty. The common thread between the unclosed style element and the lower left frame of http://www.eage.nl/student is that both have an empty body element. Quick testing reveals that if I take att404, remove the unclosed style, and remove the contents of the body element, the same bug occurs. I won't attach the stuff again :-). SUMMARY (since all my comments have been confusing): * A frame with SCROLLING="NO" and and empty BODY element displays the contents of some other frame. * I don't know how it gets there, but I see flashing of various frames in Apprunner, and this problem could be related to that one. I think just making sure that the frame with empty BODY draws itself is a bad solution, since it doesn't solve the problem of how the other frame was drawn there in the first place, a process which takes time.

Reassigning frameset/iframe bugs to Eric.

*** Bug 7477 has been marked as a duplicate of this bug. ***

If this bug still exists by then, I'll be looking into it. :)

I can't reproduce this bug anymore. Marking it worksforme, though I'm sure somebody out there labored long and hard to fix it. :)

With the Dec 15th build (1999121508), I can't reproduce the problem either.