Sometimes (fairly frequently) when I load or reload or go forward or back to this page, one of the frames will have the data of another frame in it. In one case, two of the frames were switched.

While I'm not getting the described behaviour there are some details that are not ok. With (win98 2000080108) at the top of the frames there is a line some pixels high of garbage. Could it be related to bug 47120? That bug makes to appear random cut of the page view. Perhaps the reporter saw something looking like the swap of the frames.

I'm not seeing the exact problem currently (fresh pull 8/1/00). However, I still am seeing data written into incorrect frames: often when a frame is loaded, the data from the previous frame to load is written there first. This often writes over the gaps between frames, and this leaves garbage. I.e. if there are 4 frames quartering the screen, and frame one (upper-left) loads first, then frame 2 loads: you'll see the data for frame 1 appear in frame two for an instant. If frame 1 is taller (or wider) than frame 2, it may overwrite the border between frame 2 and another frame. In one case, I saw 3 of 4 frames all loaded with the same data (the scrolling list on the left-bottom frame of www.gopconvention.com) for about 30 seconds until the other frames loaded properly.

I just saw this on Windows NT - two frames were swapped - must be an XP problem. I could not reproduce it a second time, though the first time I induce timing delays because I was stepping through the code in a debugger.

Confirmed on Linux 2000-08-11-05. Here is a way to reproduce: 1) http://www.securityfocus.com/ 2) Click on "Vulnerabilities on the left column 3) http://www.cnn.com/ 4) Click back button The result is that half of the frames have the wrong stuff in them. Screenshot attached.

In fact you can skip step 2 above. Testcase may be forthcoming.

I believe this bug is related: Go to http://dormcam.mine.nu:8080/index1.html Log In (type anything into the text box in the top right corner) The next time the message frame below the text box refreshes, it contains the data for the frame above it.

Upping severity to major; this seems like it may be indicative of an important bug (maybe a cache bug?) which could be a significant problem for final release.

I have apent a couple of hours on this and I haven't gotten anywhere. I did follow it all the way into the WebShell and then a litle further to where it was opening the URI and everything looked fine. The target was "main" the URI was correct. I am not able to figure out way it loads the same page or the default page. I am beginning to think it could be a cache bug....

I take it you can see the problem, but nothing appears wrong when tracing through things, other than the wrong data comes in for the frame. I'd suspect the cache as well, with the one caveat that I don't ever remember seeing this problem except when frames are involved. Perhaps it has to do with multiple requests being active to the cache/website?

Could be related to bug 49857

Eric - perhaps we should get a Networking Cache person on this, or at least taking a look... I agree those bugs are related.

nominating for nsbeta3 (I should note that bug 49857, which is probably the same bug, is nsbeta3-'d). This probably isn't too bad for a beta, but I would consider it a showstopper for a non-beta release, and maybe even for a late beta.

I tried turning off the cache by making the memory cache and disk cache size 0, I also set "compare the page" to never. I still see problems when going back to the original page, Although they aren't as severe. The combo boxes in the top frame appear but the contents of the lower right frame is messed up. This was using the http://www.securityfocus.com/ ==> cnn ==> back test case. There may be a two bugs here. A cache bug which prevents the combo box from showing + bug 49857. Changing component to Networking:Cache since it got better by disabling the cache. I think the other part of the bug is probably covered by 49857.

This could be the frame after clicking "Vulnerability" send no-cache. Let me see. nsbeta3+.

Betting this is one of two bugs I looked at today: Bug 53708: URLs load into wrong frames (new load wrongly detected as shist load) This bug only happens on new loads of framesets. Bug 52670: URLs load into wrong frames (shist stores frames at wrong offsets) This bug only happens on session history loads of framesets with many frames, or where one frame towards the end of the list loads much faster (e.g. from cache) than the ones before it. This sounds more like 52670, marking dup... *** This bug has been marked as a duplicate of 52670 ***

Verified dupe.