Closed
Bug 76024
Opened 24 years ago
Closed 23 years ago
Zombie Page Paints when restoring or uncovering browser (ghost)
Categories
(Core Graveyard :: GFX, defect)
Core Graveyard
GFX
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: ian, Assigned: kmcclusk)
References
()
Details
(Keywords: memory-leak, perf, regression, Whiteboard: [Hixie-P3] bad user experience)
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.
Reporter | ||
Updated•24 years ago
|
Whiteboard: [Hixie-P3] bad user experience
Comment 2•24 years ago
|
||
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.
Reporter | ||
Comment 3•24 years ago
|
||
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...
Reporter | ||
Comment 4•24 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Comment 6•24 years ago
|
||
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•24 years ago
|
||
<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•24 years ago
|
||
Would it have anything to do with bug 71516?
http://bugzilla.mozilla.org/show_bug.cgi?id=71516
Comment 10•24 years ago
|
||
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?).
Reporter | ||
Comment 12•24 years ago
|
||
Hyatt thinks this is caused by us switching alternate stylesheets.
I've also seen it when changing the font size zoom a lot.
Summary: Zombie Page Paints when restoring or uncovering browser → Zombie Page Paints when restoring or uncovering browser (ghost)
Comment 13•23 years ago
|
||
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 15•23 years ago
|
||
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?
Assignee: pierre → kmcclusk
Component: Layout → Compositor
Reporter | ||
Comment 16•23 years ago
|
||
This is now WFM. I haven't seen this for a while. My uneducated guess is it was
fixed by hyatt's style changes. ;-)
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•