I don't know how to reproduce this. Once Mozilla has hit this bug, restoring a browser window (from the minimised state) or uncovering a browser window by switching applications will cause some page that had been viewed earlier to be displayed, instead of the current page. The ghost page is drawn at the size the window was when the page was last viewed, going over any scrollbars in the content area, or, if the window was smaller before, showing some of the current page. Causing an invalidation of parts of the content area, for example by dragging the window off screen or by using the menus, will cause the correct page to be drawn in the content area, and the old page to overwrite the scrollbars. Rapidly growing the size of the window will show the old page being drawn in the gap between the location of the scroll bar immediately prior to the window resize and the new window edge. This is then overwritten by the new page as it is painted in the bigger size. I first saw this around December/January. Over the past months I have been running debug builds with the intention of catching it, and upon doing so I have attempted to step through the debugger tracking the problem down, but to no avail. Hey, I'm just QA! ;-) jst suggested that this might be caused by us leaking the original document, which might then be trying to compete with the new document when repainting. This theory is borne out by the fact that whenever I hit this bug, Mozilla's memory usage appears to be around twice what it usually floats around. This has been seen on Windows and Mac, but I haven't heard of any sightings on Linux yet. If the cause theory is correct, this could just be because it's a race condition and Linux has slightly different timings when painting. cc'ing: blake, pink and jag who claim to have seen this, bryner and jst who have given suggestions, and brendan, waterson, attinasi, hyatt, roc and dbaron who often have good insights into these things.

Is this related to bug 70139?

This wouldn't be related to using the View->Text Size feature, would it? I remember quite a while back seeing problems with that, but I don't remember the exact problem.

I thought you might be right, but then it just happened to me again without having to use the font zoom stuff at all. I've seen it happening a lot when I do many reloads of the same page over and over again, and also when using complicated stylesheets. These may or may not be related to the cause(s) of the bug...

I HAVE REPRODUCIBLE STEPS!!!! WOOOOHOOOOOO!!!!!!! TESTED WITH Windows 2000 Netscape Commercial Build 2001041620. Windows 2000 Mozilla Debug Build CVS Tip around 2001-04-17 00:00. STEPS TO REPRODUCE 1. Open the browser. 2. Go to the following URL: http://www.libpr0n.com/ 3. Go to View | Use Stylesheet | Blue 4. Click on "Home" (in the web page, not the personal toolbar home button). 5. Alt tab away from the browser so that the window is completely covered up. 6. Alt tab back. ACTUAL RESULTS Why my optimised nightly build, after step 1, memory usage is at 22,840K. Visiting libpr0n.com raises that to 23,612K. Switching stylesheets increases that to 23,768K. Clicking "Home" raises it to 24,020K and returns us to the green stylesheet. Switching away and switching back causes visible flicker as the page is first drawn in the green stylesheet, and then the page is repainted in the blue stylesheet. If between steps 4 and 5 you change the window size, then the repainted document is not sized to the new window size. Since steps to reproduce for this bug are hard to come by, I will freeze the contents of that domain until this bug has traction. NOTE: The steps don't really help us in narrowing down the source of the problem on their own, since they exercise most of layout (the stylesheets use the CSS table model, fixed positioning, alpha-blended images, backgrounds, fonts, complex selectors, alternate stylesheets, etc... It's a start though.

I notice that you're version of libpr0n has not yet been registered. Please pay the $39.95 registration fee and see if you can reproduce the bug with the registered version.

Waterson: My version *is* registered. My optimised build was registered with the key for used id 0000000045, and my debug build uses the key for user id 0000000046. I notice, however, that you have not registered *your* copy. (The registration Pav made for you during our beta period is now void.)

<Hixie> I've tried those steps on three other computers, and it only reproduces the bug on Windows, as far as I can tell.

Would it have anything to do with bug 71516? http://bugzilla.mozilla.org/show_bug.cgi?id=71516

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

I think I just saw this bug, but (as far as I can tell) I didn't switch applications, resize or minimize my Mozilla window. It just started happening suddenly. Build 2001052204, Win98.

This reminds me of the view-source-goes-blank bug that jag papered over by not using something from JS (what was it, exactly?). I suspect it has to do with us leaking something or other (like the doc viewer and thus the pres shell), and is similar to the bugscape blocker of the past few days triggered by my mistaken checkin for bug 42321. I'm guessing something similar to the incomplete patch that I attached to bug 80203 would fix this. This bug being windows-only could be explained by a windows-only leak, I guess (somewhere in widget code?).

Hyatt thinks this is caused by us switching alternate stylesheets. I've also seen it when changing the font size zoom a lot.

Tested with NS6/6.1b1, Moz (build 060603 and CVS pull_all from 06.15.01) on Win2K and Win98SE and didn't see the zombie (ghost, whatever) page. I used Ian's steps (7.14.1) on libpr0n.com and the only problem is a strip at the botom of the page that turns on white when changing CSS to "blue". However, i tested the browser on the CSS page: http://www.w3.org/Style/CSS/ and it seems to handle the different stylesheets provided on this page (10-12 different stylesheets) correctly. I was not able to compare this with other browsers be cause only the latest Mozilla(NS6.1) provides stylesheet switching. >>Ian, do you still see this on your installations?

Reassigning to pierre, based on 5/23 comments.

A ghost page cannot come from the style system. Switching stylesheets is just a way to cause a reflow within the page, like the text zoom which was mentioned as an alternate way to reproduce the problem. Per Alexandru [2001-06-15 15:21], the problem cannot be reproduced. Ian did not respond to his request. Reassigned to Compositor. WFM?

This is now WFM. I haven't seen this for a while. My uneducated guess is it was fixed by hyatt's style changes. ;-)