Closed Bug 20150 Opened 20 years ago Closed 20 years ago

Browsing area flashes garbage between page loads

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: gerbilpower, Assigned: kmcclusk)

References

Details

(Whiteboard: [PDT+] Have fix in my tree.)

Attachments

(4 files)

Build 1999112711

Steps to recreating this bug:
1. Open Mozilla and randomly visit other pages
2. notice how the viewing area briefly flashes with garbage between page
visits, kinda like TV static when changing channels.
Assignee: troy → kmcclusk
I don't see this on NT, but that may be because of the way NT initializes memory
for security reasons.

This sounds like a rendering issue. Maybe we're rendering parts of the double
buffer before it has been initialized?
Status: NEW → ASSIGNED
Target Milestone: M13
Using the 11/30 build in win95 I get the same problem when clicking on the
location bar and other text boxes.  The garbage flashes in the text box and
looks like the image surrounding it.
Example
1. Clicking the location text box you can see the toolbar's background.
This flash only occurs the first time the text box is clicked on.
*** Bug 20414 has been marked as a duplicate of this bug. ***
Target Milestone: M13 → M15
Moving to M15
Testing this on two different machines, one using a a 4MB ATI RAGE+ PCI video
card on Win95, and the other a 32 MB ATI RAGE 128 FURY SG TV AGP2x on Win98,
it looks like the severity of the problem depends on:
1. The colour bit depth
2. The specific card/driver combination

I couldn't get this problem to reproduce at all on the Win98 machine at 32 bpp,
but it showed up every time at 8bpp. On the Win95 machine, it was worst at 8bpp.

Confirmed that this doesn't happen on NT.
I see this on a k6-200 with a pci matrox mystique running in 24-bit color on
win98.  It's quite severe, you really do see it.

I also see it on a cel466 with tnt2ultra (agp) and 32-bit color.  It is
however only in the bottom half, probably because it goes so quickly it's
already drawing the correct stuff.  Changing the color depth on the cel466 down
to 8-bit made it pretty much go away.  This however could be because 8-bit is
faster and I didn't see it flash so quickly.

I'll do some more testing on the k6 when I use it next.
I have a theory on what this is.

When you first launch mozilla, the source default for the content frame is
about:blank.

Then it goes through tryToSetContentWindow() js function which then goes through
various switches and and checks to find the actual start up page. Thus causing
some "page load confusion".

This i beleive is the cause for the apparent static.

I am suggesting this because i have done some experments where i removed this
function entirely and had a page source hard coded in the <browser> tag.

The start page loads in perfectly, nice and clean.

I am in the process of rewriting these functions and others for more efficient
performance. I hope to have time this week to continue this work.

pete
That "garbage" showing up between page loads to me - by the way - looks exactly 
like the navigation toolbar. I don't know if this is the same problem, but 
that's whats showing up in the content area for me for a few milliseconds (just 
long enough to make a screen shot, by the way... my computer seems to be slow 
enough to see it).
Here it looks literally like static. No weird rendering of nearby chrome elemts, 
just pure static. It usually only occurs in a portion of the content area rather 
than the entirety. I see it on my AMD Athlon 650 with TNT2 Ultra, 32bpp, 
1024x768 under Win98 quite well. It is very noticeable. I would estimate that it 
appears for .2 to .5 seconds between the loading of most pages.
Adding myself to the CC list.
Might this be a manifestation of bug #1248 ?

If it generally happens on pages with a background
image or within image frames (the examples I've seen),
then I think that the answer is yes.

OS: Windows 98 → All
Hardware: PC → All
I can definitely confirm that Mozilla is rendering, or at least drawing itself 
(i.e. its whole window) into the content area for me (on 2 diff. computers).
I suspect that the quick change (old page -> Mozilla window -> parts of new 
page) makes it look like static, or maybe the fact that Mozilla starts drawing 
each part of the chrome and never finishes it (?) makes it look even more like 
static. - if anyone wants the screenshot, let me know...
You could be right.  From what I've seen it's adding an offset to this so that 
you get a staircase effect when it displays it though.
okay, I've been fiddling around with this a little... especially trying to get 
screen shots. First of all I realized that in full screen mode (sidebar off) 
you shouldn't get so much static, mozilla usually just draws its own window or 
parts of it.
If the window size is smaller you obviously get an offset to the whole stuff 
(as phil said), so it looks more like static. this isn't limited only to 
content "owned" by mozilla, i often get parts of window's task bar thrown in as 
well, or my desktop, or things like that. 
interesting is that i once closed mozilla, then opened it again an hour later 
or so and in all the static i could see content that i had viewed with mozilla 
that hour earlier. so i suppose it must have grabbed that somewhere from RAM 
(since disk cache or anything doesnt work yet, right?)
so yea, as it seems, the static is just the screen content most of the time.
On my system, it is not anything near recognizable as Mozilla chrome or page 
content. I will stick on a small pic approximating its appearance. It is a 
Photoshop hack since it happens to fast here to get a screenshot.
It's obvious by Jerry Baker's approximate rendering that this problem seems to
vary depending on the machine. Although it does appear like static, mine tends
to have more structure as if it's a garbled up rendering of the entire Mozilla
window.
*** Bug 25715 has been marked as a duplicate of this bug. ***
*** Bug 26001 has been marked as a duplicate of this bug. ***
OK. Anyone see the new phenomena in the browser window - The flashing of page 
content upside down and backwards? Is this the same bug, or should I file a new 
one? I will post a screen capture as an attachment.
Jerry, this is actually what I've most been experiencing on my work machine.  
It's not particularly fast (k6-200).  So the webpage upside down has been around 
for quite some time.
I have fix for this. The problem is in nsGfxScrollFrame.cpp. It sets attributes 
during the reflow of the scroll frame which causes compositing/painting to 
happen during the reflow. CC'ing evaughan. Moving to M14, changing priority to 
normal.
Severity: minor → normal
Target Milestone: M15 → M14
I'm now seeing this on my Win98 HP Laptop as of 2/1 build
Adding beta1 keyword
Keywords: beta1
PDT+ for B1 on this polish item
Whiteboard: [PDT+]
Unfortunately, my fix which prevents the GfxScrollFrame from causing a paint 
from within GfxScrollFrame::Reflow is not the right thing to do.  

The problem is the the GfxScrollFrame really needs to set the visibility of the 
horizontal and vertical scroll bars. It currently does this during Reflow 
because thats when it knows what size of it's content area is. The setting of 
the visibility is done by setting an attribute on the scrollbar's XUL element 
and using an attribute selector on a style rule in xul.css to set the visibility 
of the scrollbar. Here is the sequence that causes problems 

GfxScrollBar::Reflow(..) 
verticalScrollbar->SetAttribute(..) // Change it to visible or hidden 
Re-resolveStyle 
Paint 
Ask frames to paint  <------- This is really bad since we since we haven't 
completed the reflow which sets the position and size of the frames. It causes 
garbage to displayed between page loads because the damaged rect is copied from 
the backbuffer  but it has not been properly rendered into because its in the 
middle of reflow. 

CC'ing evaughan, GfxScrollbar guy.
I have a fix which prevents the setting of attributes during reflow from causing 
a synchronous paint.
Whiteboard: [PDT+] → [PDT+] Have fix in my tree.
Fixed in 2/9/2000 8:00am build.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
With the Feb 10 build (2000021008), I not reproducing the original problem 
described. Marking as verified fixed.
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
You need to log in before you can comment on or make changes to this bug.