76024 - Zombie Page Paints when restoring or uncovering browser (ghost)

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect)

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[hirata masakazu]

Is this related to bug 70139?

Comment 2

[Warner Young]

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.

Comment 3

[Hixie (not reading bugmail)]

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...

Comment 4

[Hixie (not reading bugmail)]

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.

Comment 5

[Chris Waterson]

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.

Comment 6

[Hixie (not reading bugmail)]

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.)

Comment 7

[Asa Dotzler [:asa]]

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

Comment 8

[Craig Kelley]

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

Comment 9

[Blake Ross]

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

Comment 10

[Warner Young]

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.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?).

Comment 12

[Hixie (not reading bugmail)]

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

Comment 13

[Alexandru Savulov]

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?

Comment 14

[karnaze (gone)]

Reassigning to pierre, based on 5/23 comments.

Comment 15

[Pierre Saslawsky]

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?

Comment 16

[Hixie (not reading bugmail)]

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