Closed Bug 242856 Opened 20 years ago Closed 20 years ago

Slow image, text, view source rendering / page takes long time to load or blank

Categories

(Core Graveyard :: Image: Painting, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mmoy, Assigned: roc)

References

Details

(Keywords: perf, regression)

Attachments

(4 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504 Firefox/0.8.0+ (mmoy-Pentium3F)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040504 Firefox/0.8.0+ (mmoy-Pentium3F)

I noticed some strange image loading behaviour in a build that I did this morning.
My last build was on 5/3 and I didn't see the bahviour from that build.

I have a homepage with several small images on it which link to larger versions
of the images and they are all local to my hard drive. When I click on one of the
smaller images, the page area is blanked out (white) for a moment before the
image is displayed. Sometimes, this blank time is a fraction of a second and
sometimes it's as long as three seconds.

The image paints very quickly after the pause so it appears that something's going
on that's not related to image painting.

I also noticed this with the MozillaZine png at the top of the page though it
is very short there as the PNG is probably fairly small.

Someone pointed me to this checkin as a possibility.

Reproducible: Always
Steps to Reproduce:
1.Pull up a moderately sized image and hit the back button.
2.
3.

Actual Results:  
There is a pause from page to image and back again. Sometimes it's a fraction of a second and sometimes it's a few seconds.

Expected Results:  
Speed-of-light rendering.

See note 35 in http://bugzilla.mozilla.org/show_bug.cgi?id=236313 and
post at http://forums.mozillazine.org/viewtopic.php?p=514604#514604 at

infiniteedge Joined: 19 Oct 2003 Posted: Thu 6th May 2004 3:36pm     

for others that have seen this problem.
Keywords: perf
So what exact page can one test this on?

Can you possibly narrow the regression range (eg using nightlies) to a day or so?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040506
Firefox/0.8.0+
installer build, no extensions

i'm infiniteedge.  i only saw this starting with the 05/06 build.  using
yesterday's 05/05 build I didn't notice this problem.
What are the exact build (or rather pull) times?   And again, where can I test this?
i'm using the official build, so whatever build time that one has.  and the
first place i noticed it was www.truevalue.com

i'm experiencing it at random pages.  i'll try to take note of them as they
happen.  just overall, page loading seems sluggish and delayed, on any page.
> i'm using the official build, so whatever build time that one has

Yes, but what is it?  Just list the ua string, please.

And it'd help a lot to have something better to go on than "slow and sluggish"....
My pull was 8:00 AM EDT today (May 6). My previous build was 5/3 so that probably
isn't that helpful as far as isolating the code change.

If you have a 1.5 to 2 MB image on your hard drive, create a page to link to it
and then click on the link and then hit the back key. I have a bunch of images
linked like this and most exhibit this behaviour.

Slow and sluggish to me means going from 1 second to render and image to three
seconds. I'm on a 2 Ghz Pentium 4 with gobs of memory and 1 second to render a
moderately large JPEG is normal for this system.
Could those seeing this problem try a new profile?
> If you have a 1.5 to 2 MB image on your hard drive

I don't...

The checkins between 12:01am on May 5 and 8am on May 6 are:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-05+00%3A01%3A00&maxdate=2004-05-06+08%3A00%3A00&cvsroot=%2Fcvsroot

The suspicious one is bug 236313 (I know you said you tried backing that out)
and maybe bug 233441.  Everything else shouldn't be affecting this.
Hi,
I'm seeing this too.

First showed up for me in
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040506
Firefox/0.8.0+ (May 06 build)
I did not see this in
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040505
Firefox/0.8.0+  (May 05 build)

Though for me this does not depend on having to render an image.

I also noticed that the View > Page Source seems to be slower too?  I'm not
really sure about this since I don't use it much.

Some test cases i'm using to follow...
Are people seeing this with SeaMonkey too?  Or just Firefox?
Attached file Basic Test Cases
three files in one archive...you need to download them all anyway.
Page 1 links an image (the bugzilla ant), Page 2 and 3 just have different
background colors.

Steps to Reproduce:
1. Download the three test cases and load Page1.html in a new browser window
2. Load Page2.html then Page3.html
3. Click back and forward buttons to view the test pages (no delay here for me)

4. Open a new tab and close the new tab (I don't get why this does anything
but...)
5. Click back and forward buttons again (this time I see the page rendering
lag)

Actual Results:
There is a delay up to ~3 seconds before the page loads where the background
color of the previous page shows.
Attachment #147863 - Attachment mime type: application/octet-stream → application/zip
Those steps workforme with a Linux trunk Seamonkey nightly from 2004-05-06-08.
I'm definitely seeing this on FF.  Especially when going back pages.  There is a
white space for maybe 2-3 seconds before the image appears.  And most of the
time, the rest of the page (i.e. text, etc.) doesn't appear until the images
appear.  Previously, this did not happen and everything was lightning fast.

UA: Mozilla/5.0 (Windows; compatible; U; Windows NT 5.1; en-US; rv:1.8a)
Gecko/20040506 Firefox/0.8.0+
duplicate of 242843? I bet it's a regression from 233441
roc, that first bug# seems to be wrong afaict?
Depends on: 242823
See the same behaviour with the testcase of comment #11 using Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040507 Firefox/0.8.0+

But it works fine with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a)
Gecko/20040505 and Mozilla 1.7 RC1

So it seems to be a Firefox only bug.

Bruno
(In reply to comment #17)
> But it works fine with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a)
> Gecko/20040505 and Mozilla 1.7 RC1
> 
> So it seems to be a Firefox only bug.
> 
> Bruno

I was able to reproduce on a mozilla trunk nightly. Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.8a) Gecko/20040507 on Windows 2000
Note that this bug first appears starting 2004-05-06
Attached image Screenshot of bug
I've been experiencing some latency in screen draws as well that *might* be
this bug, or perhaps another.  I'm really not sure.  Started about the same
time.

Attached is a screenshot loading google.  Notice the form appears, there's
about a 1-2 second delay, then the rest just magically appears.  Strange.  

I noticed the same thing when creating this attachment.  Form elements
appeared, while the rest of the page loaded a second or two later.

Perhaps form related?  I don't know.

Hopefully this helps.
I believe that this problem is actually two problems. One caused by a checkin after 8 PM and one caused by a checkin between noon and 8 PM. At any rate, the
problem is not there before noontime.
I've been seeing similar "strangeness" with Mozilla 5/07-08 under XP.  Most
reproducible for me is simple google.com.  The first time I go there upon
starting the browser, it will also display only a white background with the
blinking cursor from the search box.  About 3 seconds later the whole screen
will be drawn. Subsequent visits in the same browser session work correctly. 
But if I exit Mozilla and run it again the same thing happens.

This is also happening on other sites, but it's somewhat random - however, I
have noticed an overall "pause" in rendering anything (although not always as
noticeable as Google) upon initial rendering.

As with other reports, I only first noticed this in a 5/7 build.  But it's
definitely Seamonkey too.
Oh, and not form related.  I've experienced this on sites without any forms. 
(One of my own site's sub-pages actually.)
Keywords: regression
I'm thinking two things here:

UTF8

or

gzip encoded.

One last note:

It's not just images.  I've got a few text files I'm viewing (Content-Type:
text/html), and it does this as well.  And there is no images in there (pure text)

But google is the easiest to reproduce.
The problem doesn't occur before 16:00 code checkins. But it does occur before 20:00. As I said before, I think that there is more than one checkin problem here
but the first has been narrowed down.
(In reply to comment #25)
> The problem doesn't occur before 16:00 code checkins. But it does occur before
20:00.

which timezone, and what day (may 6?)?
My times are PDT on 5/5.
*** Bug 243066 has been marked as a duplicate of this bug. ***
The checkin report that I'm using seems to be an hour ahead of PDT after I did a comparison of checkins to the code from my pull. It's pointing to roc's change at the moment.
The second problem is in there at 23:00 PDT. The first problem is what I'd call a flicker. The second problem is a pause. It seems to me that the developers have
enough to go on at this point as far as narrowing down checkins goes.
I don't seem to be experiencing "flickering" per say, so maybe I'm getting the
other problem mentioned here. For me, occasionally when the browser finishes
loading I have just a blank white page. When I give the browser any kind of
input (a click in the browser pane or on a button, or touch the scroll wheel,
ect) then the page instantly renders. If I do not give the browser any input, it
will sit at a white page indefinetely and never actually draw the rendered page.
I'm noticing this in Stipe and Bluefyre's builds from yesterday (5/9) and the
5/8 official nightly. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040509
Firefox/0.8.0+
I'm 90% sure that the 1st of May build didn't have this problem.
I'm seeing this on yesterday's Win32 and Linux Firefox builds (haven't tested
Seamonkey).

If I had to describe it, I'd say that page loading is often sluggish, and on
pages where it is sluggish there is often flickering or flashing in the browser
window before it renders completely, at which point it looks fine. Yes, I know
its vague, but its the best I have right now.
OS: Windows XP → All
Hardware: PC → All
www.neowin.net is the prime example for me. It's painfully slow on the front 
page.
I don't have any problems accessing neowin.net here - could it be to do with
websites loading from the cache?

I have only seen the problem on sites that I visit regularly.
Blocks: 243195
i second comment #35. It`s the same here. 
For example a IPB/forum I visit every day. The user pics (Called avatars) should
come from cache, so I guess this is the problem
using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040509
Firefox/0.8.0+
FWIW: What I'm seeing has nothing to do with cached information.  I only get
slow rendering the 1st time I go to a "problem" site in each browser session. 
Subsequent visits in the same session render immediately.  (Exiting Mozilla, and
restarting it, then going to the same site exhibits the slow rendering again -
but just the first time.)  Clearing the cache or not has no impact on these
symptoms.  (This is under XP).
In response to comment #35, I see this problem with my disk cache disabled (it's
how I've been browsing for several months now).  Now, of course, the memory
cache is still enabled, so perhaps there is a problem there.
Something else I'm seeing (build 20040512, WinXP) when loading up image-only
files: I can see part or all of the image flash very briefly, then the page
turns blank, and after a short time, the image appears.  I'm wondering if this
is related.  I saw this when clicking on the images from this page:
http://www.homelanfed.com/index.php?id=23315
Attached patch trial patch (obsolete) — Splinter Review
Can someone who sees this problem and can build Mozilla try this patch to see
if it fixes the problem? I don't know exactly what the problem is but if this
patch fixes it, I can narrow it down.
Assignee: jdunn → roc
Status: NEW → ASSIGNED
Someone on the unofficial build forums tried it last night and noticed a change in behaviour (maybe a little faster) but the general impression is that it isn't fixed. There will be a few others building with this patch today. I'm pulling the
current tree and will do a build later this morning to try it out since it is so
easy for me to see the problem.

http://forums.mozillazine.org/viewtopic.php?t=76722
The other thing you should do is try backing out the patch in bug 233441.
Is there a way of applying all of the patches at once without breaking them into smaller patch files?
using the patch command,

patch -p0 < patchfile

while you're in the 'mozilla' directory.
Build is running with the patch. I'll try removing the other patch later on.

Do you have the command to undo a patch? I tried using the reverse patch command
a while ago but couldn't get it to work.

The build should be done in about 2.25 hours.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040514 (djeter)

Well just finished installed djeter optimised builds that included the trial
patch.I still seen this problem after following the comments #11 steps.Using the
back button,i can see the delayed page1(ant) and page3 (green color) delayed
about few seconds.I guess this patch doesnt work.
My build finished and I still see the pause problem. Actually it seems worse than
when I last tested it. I didn't see the flicker problem but it may be that the
pause was so long that it's masking the flicker problem.

If someone could show me how to backout a patch, I'll do that and rebuild and try again.
The pause/flicker problem is there (I did some more testing). I only did a little
testing earlier as this build wiped out my profile and I had to get something
usable.
I tried reversing the patch but got a number of errors on the attempt. That's
about all the time that I have to work on this one today. If you can come up
with a patch to undo that patch, post it here or at the unofficial builds board
and I'm sure a few folks will try a build.

F:\Mozilla\mozilla>patch -p0 -R < f:\mozilla\unpatch.txt
patching file accessible/src/base/nsCaretAccessible.cpp
patching file accessible/src/base/nsDocAccessible.cpp
patching file content/base/src/nsContentSink.cpp
Hunk #1 succeeded at 975 (offset -67 lines).
patching file content/base/src/nsDocumentViewer.cpp
Hunk #1 succeeded at 453 (offset -3 lines).
Hunk #2 succeeded at 1650 (offset -7 lines).
Hunk #3 succeeded at 1841 (offset -7 lines).
Hunk #4 FAILED at 1905.
Hunk #5 succeeded at 1931 (offset -7 lines).
1 out of 5 hunks FAILED -- saving rejects to file content/base/src/nsDocumentViewer.cpp.rej
patching file content/base/src/nsPrintEngine.cpp
Hunk #1 succeeded at 231 (offset -2 lines).
Hunk #2 FAILED at 2618.
Hunk #3 succeeded at 2656 (offset -13 lines).
Hunk #4 succeeded at 2705 (offset -13 lines).
Hunk #5 succeeded at 4750 (offset -13 lines).
1 out of 5 hunks FAILED -- saving rejects to file content/base/src/nsPrintEngine.cpp.rej
patching file docshell/base/nsDocShell.cpp
Hunk #1 succeeded at 1600 (offset 19 lines).
Hunk #2 succeeded at 3281 (offset 15 lines).
patching file dom/src/base/nsGlobalWindow.cpp
Hunk #1 FAILED at 4415.
Hunk #2 succeeded at 4321 (offset -139 lines).
Hunk #3 succeeded at 4350 (offset -139 lines).
Hunk #4 succeeded at 5693 (offset -163 lines).
1 out of 4 hunks FAILED -- saving rejects to file dom/src/base/nsGlobalWindow.cpp.rej
patching file editor/libeditor/text/nsEditorEventListeners.cpp
patching file extensions/inspector/base/src/inLayoutUtils.cpp
patching file extensions/layout-debug/src/nsLayoutDebuggingTools.cpp
patching file layout/html/base/src/nsContainerFrame.cpp
patching file layout/html/base/src/nsObjectFrame.cpp
Hunk #1 succeeded at 1767 (offset -2 lines).
Hunk #2 succeeded at 1803 (offset -2 lines).
patching file layout/html/base/src/nsPresShell.cpp
Hunk #2 succeeded at 5802 (offset 51 lines).
Hunk #3 succeeded at 6431 (offset 50 lines).
Hunk #4 FAILED at 7016.
1 out of 4 hunks FAILED -- saving rejects to file layout/html/base/src/nsPresShell.cpp.rej
patching file layout/html/document/src/nsFrameSetFrame.cpp
Hunk #1 succeeded at 1509 (offset -28 lines).
patching file layout/html/style/src/nsCSSFrameConstructor.cpp
Hunk #1 succeeded at 3649 (offset 1 line).
patching file layout/html/style/src/nsCSSRendering.cpp
patching file layout/html/tests/table/TableContentTest/TableContentTest.cpp
Hunk #1 FAILED at 475.
1 out of 2 hunks FAILED -- saving rejects to file layout/html/tests/table/TableContentTest/TableContentTest.cpp.rej
patching file layout/xul/base/src/nsMenuPopupFrame.cpp
patching file view/public/nsIView.h
patching file view/public/nsIViewManager.h
Hunk #2 FAILED at 67.
Hunk #3 FAILED at 507.
2 out of 3 hunks FAILED -- saving rejects to file view/public/nsIViewManager.h.rej
patching file view/src/nsView.cpp
Hunk #2 FAILED at 246.
Hunk #3 succeeded at 749 (offset 3 lines).
1 out of 3 hunks FAILED -- saving rejects to file view/src/nsView.cpp.rej
patching file view/src/nsViewManager.cpp
Hunk #1 FAILED at 446.
Hunk #2 FAILED at 535.
Hunk #3 FAILED at 554.
3 out of 3 hunks FAILED -- saving rejects to file view/src/nsViewManager.cpp.rej
patching file view/src/nsViewManager.h
Hunk #1 FAILED at 120.
Hunk #2 FAILED at 348.
Hunk #3 succeeded at 375 (offset 1 line).
2 out of 3 hunks FAILED -- saving rejects to file view/src/nsViewManager.h.rej
patching file webshell/tests/viewer/nsBrowserWindow.cpp
patching file webshell/tests/viewer/nsWebCrawler.cpp
patching file webshell/tests/viewer/nsXPBaseWindow.cpp
patching file widget/src/xpwidgets/nsBaseFilePicker.cpp

F:\Mozilla\mozilla>
I don't know why the patch -R didn't succeed for you, but you can get checkout
clean and unmodified versions of the files where it failed with
cvs upd -C files
called from the mozilla directory, where files is a space separated list of
filenames with full paths.
I'm thinking that some of the files have changed since the code checkin went in.
It may work better to try backing out the code change with a pull from 5/6 instead
of a current one. At any rate, I can't access CVS during the day so Saturday night
is the earliest that I could do anything more with this problem.
I'm not sure which patches you tried. You tried backing out 233441 and that
didn't fix the problem?
I tried the patch posted in this bug and tried backing out the patch in the bug that you referenced. The backout of the second patch didn't work so I didn't run a build on it.

I could try a build with the removal of the old patch with an earlier checkout but
then your patch might not work if some of the files that your patch references
have changed since 5/5.

At any rate, I'm not planning on doing any of this stuff until tomorrow night or
Sunday at the earliest. You might put a post in the unnofficial builders forum if
you want to see if you can find another builder to try stuff out.
Flags: blocking1.8a?
(In reply to comment #9)

> Though for me this does not depend on having to render an image.
> 
> I also noticed that the View > Page Source seems to be slower too?  I'm not
> really sure about this since I don't use it much.

I see an overall slowdown in rendering too.  I don't think it's just limited to
just images.  Viewing page source seems equally slow as well.
*** Bug 243707 has been marked as a duplicate of this bug. ***
Tweaking summary to include all of the symptoms reported so far so as to try to
prevent future dupes.  Note that bug 242823 (despite it being a lower number,
this one has more activity and votes) and bug 243195 are likely just dupes of
this one too.
Summary: Slow image rendering → Slow image, text, view source rendering / page takes long time to load or blank
I've tried backing out the patch in bug 233441 and had similar errors to those
in comment #49.  Some changes that were applied seem different from what is in
the patch...?
Not trying to spam this bug, I hope this is on topic enough... I found this on
David Hyatt's blgo from yesterday. In talking a bit about Safari's page
rendering, this little bit came out, the bottom portion sounds an AWFUL lot like
what has been happening for me. One small element will load instantly... and
then there will be up to a 1.5 to 2 second delay before the other stuff comes
in. Anyhow, here it is:
----------------
When I implemented this algorithm (called "paint suppression" in Mozilla
parlance) in Mozilla I originally used a delay of 1 second, but this led to the
perception that Mozilla was slow, since you frequently didnt see a page until it
was completely finished. Imagine for example that a page is completely done
except for images at the 50ms mark, but that because you're a modem user or DSL
user, the images aren't finished until the 1 second mark. Despite the fact that
all the readable content could have been shown at the 50ms mark, this delay of 1
second in Mozilla caused you to wait 950 more ms before showing anything at all.

One of the first things I did when working on Chimera (now Camino) was lower
this delay in Gecko to 250ms. When I worked on Firefox I made the same change.
Although this negatively impacts page load time, it makes the browser feel
substantially faster, since the user clicks a link and sees the browser react
within 250ms (which to most users is within a threshold of immediacy, i.e., it
makes them feel like the browser reacted more or less instantly to their command).

Firefox and Camino still use this heuristic in their latest releases. Safari
actually uses a delay of one second like older Mozilla builds used to, and so
although it is typically faster than Mozilla-based browsers on overall page
load, it will typically feel much slower than Firefox or Camino on network
connections like cable modem/modem/DSL.

However, there is also a problem with the straight-up time heuristic. Suppose
that you hit the 250ms mark but all the stylesheets haven't loaded or you
haven't even received all the data for a page. Right now Firefox and Camino
don't care and will happily show you what they have so far anyway. This leads to
the "white flash" problem, where the browser gets flashy as it shows you a blank
white canvas (because it doesn't yet know what the real background color for the
page is going to be, it just fills in with white).
The pauses that I'm seeing can last for a lot longer than a second. At any rate, the easiest thing to do may be to just remove the offending checkins.
(In reply to comment #58)
> Try using this to do the backount instead:
> 
>
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-05-05+20%3A16&maxdate=2004-05-05+20%3A18&cvsroot=%2Fcvsroot&generateBackoutCVSCommands=1

The patch for bug 242833 also needs to be dealt with since it uses RootView()
So I backed out that patch as well to get it to compile and the rendering delay
is gone.
(In reply to comment #61)

> The patch for bug 242833 also needs to be dealt with since it uses RootView()
> So I backed out that patch as well to get it to compile and the rendering delay
> is gone.

Thanks for the post. I was in the middle of pulling but I'll kill that as
the offending code changes have been found.
We can back out 233441, but the problem is that I can't easily reproduce this so
then it will be hard for me to fix the underlying problem.
(In reply to comment #63)
> We can back out 233441, but the problem is that I can't easily reproduce this so
> then it will be hard for me to fix the underlying problem.

Builders and testers on the trunk are dropping like flies because of this and
other instabilities in the trunk. I can reproduce the problem very easily and
maybe there are a few others in the same situation that can help you out.

In my case, I have a home page (local) that has a lot of images of about 1 MB
on it (also local). Just clicking back and forth shows the problem. This is on
Windows XP.

It would also be nice to test with the code base from early May as opposed to
now as the current code kills your profile. I accidently blew away two profiles
last week doing some testing. Lots of other complaints about that problem in the
forums.

I can build and test but turnaround time could be an issue for you.
I agree with backing out the changes. The 65 votes in a VERY SHORT timespan
indicate how important this is to people. Testers will put up with a lot, but a
slow browser is not normally one of them.
I'm going to back it out now.
I'll try a build tonight to see how it goes (with a new profile of course).

Unless someone beats me to it. For those testing, just be aware that extensions
get trashed in recent nightlies.
Can an automatic regression timing-test be developed to help catch perf
regressions like this sooner?  Apparently the regression doesn't show up in
existing tp load tests.
This is not a performance regression. The page loads at normal speed, it just
doesn't display properly until it has finished loading.

My current theory is that the paint suppression timer somehow fails to redraw
the page when it goes off.
Michael, while you still have a build showing this problem, could you try a test
for me?  Put a printf in PresShell::UnsupressPainting and another in
PresShell::UnsuppressAndInvalidate.  Are they being called during pageload?

Also, does backing out just the nsContentSink change help anything?  (I'm not
sure why that code was removed, exactly...)
The root view never QIs to nsIScrollableView, so that code in nsContentSink
never does anything.
(In reply to comment #71)
> Michael, while you still have a build showing this problem, could you try a test
> for me?  Put a printf in PresShell::UnsupressPainting and another in
> PresShell::UnsuppressAndInvalidate.  Are they being called during pageload?
> 
> Also, does backing out just the nsContentSink change help anything?  (I'm not
> sure why that code was removed, exactly...)

I don't have a build for that on my machine at the moment. I'll give it a try
tonight though. I assume that you're talking about a debug build as I don't think
that printf does anothing in a release build.
Printf works just fine in any build that you can run on a console.  I have no
idea how that all works in Windows, of course; on Linux it Just Works.

re: content sink, heh.
I sometimes use dump() in javascript code. On Windows, you have to use the
-console switch: A console window appears, showing the output of the dumps etc.
-console works.
I did a pull, added the printfs and the build has been running for about 30 minutes. Should take another 90 minutes. I didn't back out the other change
that Matthew Imakyure referred to as the backout should have removed the
dependency for backing out.
The problem is gone with the code pull from this evening. And those two routines
that were requested via printf showed up going forwards and backwards.

One other note is that I didn't see the problem with a clean profile. With my
normal set of extensions (Tab Browser Extensions, Context Menu Extensions and
EZ-Sidebar), the problem is seen. Now the more recent nightlies kill your
extensions so I had to restore them from backup with each run. But this profile
was created with a 5/5 build and the problem was seen just afterwards sos I think
that it's unlikely that a profile structure change displays this problem.

It could be that one of the extensions makes the problem visible.

Context Menu Extensions is something that very few people install. EZ-Sidebar
probably has more users but isn't widely known.

So it may be that TabBrowser Extensions is a prerequisite for seeing this problem. Or maybe an extension that does something similar to TBE. Could someone
that has seen this problem that ISN'T running TBE raise their hand to dispel
this theory?
I do not use TBE and did not see the problem.
I have NO EXTENSIONS installed, and I see the problem.
I don't have any of the extensions you mentioned, and I see the problem.  I
think that this has nothing to do with extensions.
> The problem is gone with the code pull from this evening

Er... the point was to put those printfs into a build that _did_ have this
problem, to try to diagnose it a little bit...  Was comment 71 really that unclear?
I don't have any of the extensions you mentioned, and I see the problem.  I
think that this has nothing to do with extensions.
I don't have any of the extensions you mentioned, and I see the problem.  I
think that this has nothing to do with extensions.
! Collisions all over the place as I tried to reply - I even ended up colliding
with myself.  From the flood of comments, I shouldn't have bothered saying anything.
(In reply to comment #82)
> > The problem is gone with the code pull from this evening
> 
> Er... the point was to put those printfs into a build that _did_ have this
> problem, to try to diagnose it a little bit...  Was comment 71 really that unclear?

It's been a busy day and I've had to do a whole bunch of unrelated stuff. I'll
do another pull and try again.
Did anyone reproduce this with a GTK2 build? If so, what was the build config?
(In reply to comment #87)
> Did anyone reproduce this with a GTK2 build? If so, what was the build config?

I said that I did in comment 33, but I haven't seen it again on Linux (to my
recollection), so maybe I was just imagining things at the time. I definitely
see it on Win32 though (using a build from two days ago).

Since I set it to All/All from PC/Windows XP, and I can't (at this point) think
of a good reason to keep it that way, I'm reverting the change. Someone can
switch it back to All/All if they still see this on Linux.
OS: All → Windows XP
Hardware: All → PC
I did the build with the problem in it from May 6 and those two routines do show
up in the console when going back and forth between pages which display the slow
rendering problem.

I'll leave the build environment around for a while in case there are any other
requests.
When do they show up though, compared to the rendering?  That is, what's the
order of load start, those two printfs, and the painting of the page?
Flags: blocking1.8a? → blocking1.8a-
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520
SeaMonkey(djeter).

FYI, i don't seeing this bug on djeter latest SeaMonkey optimised builds.Running
on WinXp.But seeing this in SeaMonkey before; as i said in my comment #46.I
assumed its something to do with backout checkin on 20040517...i guess.
Are there people other than me who could not reproduce this? I've restored the
233441 patch in my local build and I still can't see any of these problems :-(.
I'm wondering if there's something different about my setup that triggers it.
I could never reproduce it either (gtk1 builds of all stripes, from nightlies to
my own builds, on Linux).

Though the comments in this bug do seem to indicate that this was Windows-only... :(
I'm pretty sure it's windows only.

I've see it in Tbird as well.
Attached patch trial patch 2Splinter Review
Can someone who saw this bug on Windows please try this patch. It's the patch
for 233441, updated to the trunk, with more aggressive invalidation in
nsPresShell::UnsuppressAndInvalidate. I hope that it will fix this problem.
(In reply to comment #95)
> Created an attachment (id=149179)
> trial patch 2
> 
> Can someone who saw this bug on Windows please try this patch. It's the patch
> for 233441, updated to the trunk, with more aggressive invalidation in
> nsPresShell::UnsuppressAndInvalidate. I hope that it will fix this problem.

I have a 5/6 environment on my machine right now and can try a build with this
patch. Is this patch meant to be applied to an environment with the problem or
without?
Without. This patch applies to a clean checkout of the current trunk.
(In reply to comment #97)
> Without. This patch applies to a clean checkout of the current trunk.

Well, I'll give it a try after I get home tonight unless someone else beats me
to it.
I just tried compiling a Firefox trunk build with the patch. It appears (at
least for me) to partially work. The page rendering is quicker. However, in when
you click "View Page Source", it still takes a while to load.
Page Source is often slow even when there aren't any bugs. I need to know
whether applying this patch makes any noticeable slowdown over the current trunk.
I'll give it a try tonight. I didn't know if the previous poster's response was
adequate.
Just did a pull and tried the patch. There was a failure though as listed below.

F:\Mozilla\mozilla>patch -p0 < mike.patch
patching file accessible/src/base/nsCaretAccessible.cpp
patching file accessible/src/base/nsDocAccessible.cpp
Hunk #1 succeeded at 436 (offset 17 lines).
patching file content/base/src/nsContentSink.cpp
patching file content/base/src/nsDocumentViewer.cpp
patching file content/base/src/nsPrintEngine.cpp
patching file docshell/base/nsDocShell.cpp
patching file dom/src/base/nsGlobalWindow.cpp
Hunk #1 succeeded at 4296 (offset 20 lines).
Hunk #2 succeeded at 4318 (offset 20 lines).
Hunk #3 succeeded at 4345 (offset 20 lines).
Hunk #4 succeeded at 5686 (offset 20 lines).
patching file editor/libeditor/text/nsEditorEventListeners.cpp
patching file extensions/inspector/base/src/inLayoutUtils.cpp
patching file extensions/layout-debug/src/nsLayoutDebuggingTools.cpp
patching file layout/html/base/src/nsContainerFrame.cpp
patching file layout/html/base/src/nsObjectFrame.cpp
patching file layout/html/base/src/nsPresShell.cpp
patching file layout/html/document/src/nsFrameSetFrame.cpp
patching file layout/html/style/src/nsCSSFrameConstructor.cpp
patching file layout/html/style/src/nsCSSRendering.cpp
patching file layout/html/tests/table/TableContentTest/TableContentTest.cpp
patching file layout/xul/base/src/nsMenuPopupFrame.cpp
patching file view/public/nsIView.h
patching file view/public/nsIViewManager.h
patching file view/src/nsView.cpp
patching file view/src/nsViewManager.cpp
patching file view/src/nsViewManager.h
Hunk #2 FAILED at 346.
1 out of 3 hunks FAILED -- saving rejects to file view/src/nsViewManager.h.rej
patching file webshell/tests/viewer/nsBrowserWindow.cpp
patching file webshell/tests/viewer/nsWebCrawler.cpp
patching file webshell/tests/viewer/nsXPBaseWindow.cpp
patching file widget/src/xpwidgets/nsBaseFilePicker.cpp

Here are the contents of the reject file:

***************
*** 350,362 ****
     * @param aMaxWidgetBounds the maximum width and height of all view managers
     * widgets on exit.
     */
    void GetMaxWidgetBounds(nsRect& aMaxWidgetBounds) const;
  
  public: // NOT in nsIViewManager, so private to the view module
-   nsView* GetRootView() const { return mRootView; }
    nsView* GetMouseEventGrabber() const;
          nsView* GetKeyEventGrabber() const { return mKeyGrabber; }
  
    nsEventStatus HandleEvent(nsView* aView, nsGUIEvent* aEvent, PRBool aCaptured);
  
    /**
--- 346,358 ----
     * @param aMaxWidgetBounds the maximum width and height of all view managers
     * widgets on exit.
     */
    void GetMaxWidgetBounds(nsRect& aMaxWidgetBounds) const;
  
  public: // NOT in nsIViewManager, so private to the view module
+   nsView* RootView() const { return mRootView; }
    nsView* GetMouseEventGrabber() const;
          nsView* GetKeyEventGrabber() const { return mKeyGrabber; }
  
    nsEventStatus HandleEvent(nsView* aView, nsGUIEvent* aEvent, PRBool aCaptured);
  
    /**
Fix the reject by fixing up the file to look like the second half of the reject
file, thanks!
I changed the file as you suggested and tried the patch again but I don't
think that it worked. The output is below.

F:\Mozilla\mozilla>patch -p0 < f:\mozilla\mozilla\mike.patch
patching file accessible/src/base/nsCaretAccessible.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file accessible/src/base/nsCaretAccessible.cpp.rej
patching file accessible/src/base/nsDocAccessible.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file accessible/src/base/nsDocAccessible.cpp.rej
patching file content/base/src/nsContentSink.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file content/base/src/nsContentSink.cpp.rej
patching file content/base/src/nsDocumentViewer.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file content/base/src/nsDocumentViewer.cpp.rej
patching file content/base/src/nsPrintEngine.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
5 out of 5 hunks ignored -- saving rejects to file content/base/src/nsPrintEngine.cpp.rej
patching file docshell/base/nsDocShell.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file docshell/base/nsDocShell.cpp.rej
patching file dom/src/base/nsGlobalWindow.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file dom/src/base/nsGlobalWindow.cpp.rej
patching file editor/libeditor/text/nsEditorEventListeners.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file editor/libeditor/text/nsEditorEventListeners.cpp.rej
patching file extensions/inspector/base/src/inLayoutUtils.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file extensions/inspector/base/src/inLayoutUtils.cpp.rej
patching file extensions/layout-debug/src/nsLayoutDebuggingTools.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file extensions/layout-debug/src/nsLayoutDebuggingTools.cpp.rej
patching file layout/html/base/src/nsContainerFrame.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file layout/html/base/src/nsContainerFrame.cpp.rej
patching file layout/html/base/src/nsObjectFrame.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file layout/html/base/src/nsObjectFrame.cpp.rej
patching file layout/html/base/src/nsPresShell.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
5 out of 5 hunks ignored -- saving rejects to file layout/html/base/src/nsPresShell.cpp.rej
patching file layout/html/document/src/nsFrameSetFrame.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file layout/html/document/src/nsFrameSetFrame.cpp.rej
patching file layout/html/style/src/nsCSSFrameConstructor.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file layout/html/style/src/nsCSSFrameConstructor.cpp.rej
patching file layout/html/style/src/nsCSSRendering.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file layout/html/style/src/nsCSSRendering.cpp.rej
patching file layout/html/tests/table/TableContentTest/TableContentTest.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file layout/html/tests/table/TableContentTest/TableContentTest.cpp.rej
patching file layout/xul/base/src/nsMenuPopupFrame.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
5 out of 5 hunks ignored -- saving rejects to file layout/xul/base/src/nsMenuPopupFrame.cpp.rej
patching file view/public/nsIView.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file view/public/nsIView.h.rej
patching file view/public/nsIViewManager.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file view/public/nsIViewManager.h.rej
patching file view/src/nsView.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file view/src/nsView.cpp.rej
patching file view/src/nsViewManager.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file view/src/nsViewManager.cpp.rej
patching file view/src/nsViewManager.h
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file view/src/nsViewManager.h.rej
patching file webshell/tests/viewer/nsBrowserWindow.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file webshell/tests/viewer/nsBrowserWindow.cpp.rej
patching file webshell/tests/viewer/nsWebCrawler.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file webshell/tests/viewer/nsWebCrawler.cpp.rej
patching file webshell/tests/viewer/nsXPBaseWindow.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file webshell/tests/viewer/nsXPBaseWindow.cpp.rej
patching file widget/src/xpwidgets/nsBaseFilePicker.cpp
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file widget/src/xpwidgets/nsBaseFilePicker.cpp.rej
No no, edit view/src/nsViewManager.h to look like this:

     * @param aMaxWidgetBounds the maximum width and height of all view managers
     * widgets on exit.
     */
    void GetMaxWidgetBounds(nsRect& aMaxWidgetBounds) const;
  
  public: // NOT in nsIViewManager, so private to the view module
    nsView* RootView() const { return mRootView; }
    nsView* GetMouseEventGrabber() const;
          nsView* GetKeyEventGrabber() const { return mKeyGrabber; }
  
    nsEventStatus HandleEvent(nsView* aView, nsGUIEvent* aEvent, PRBool aCaptured);
  
    /**
That's what it looks like now. Should I just run the build now? I wasn't sure
if I needed to run the patch again.
Great! When you apply a patch, the changes stick (except for the rejects). Go
ahead and build and try it out... Thanks!
The flickering problem is still seen though it's only when I hit the back key to
return to a previous page. I didn't see it going forward to a link.

I forgot to backup my profile and this build did some funny things to it though
not as bad as some from a few weeks ago. I was able to recover after going back
to my stable FireFox. I have a few backups but they're a bit old. Fortunately
I don't think that I lost anything.
When I first saw this problem, there was a pause/flicker going to images and
one coming back. With this code, there is no pause/flicker going to images but
there is one when hitting the back button.

The worst case was a three-second pause. Most of the time when I saw this
problem, there was a flicker. I did not see the problem on a new profile but installing TBE on a new profile showed the problem right away.

(In reply to comment #109)
> Not sure what you mean by "the flickering problem" ... do you see the same
> problems as reported here
> 
> http://bugzilla.mozilla.org/show_bug.cgi?id=242856#c11
> http://bugzilla.mozilla.org/show_bug.cgi?id=242856#c13
> http://bugzilla.mozilla.org/show_bug.cgi?id=242856#c21
> http://bugzilla.mozilla.org/show_bug.cgi?id=242856#c31
> 
> ?

> The worst case was a three-second pause.

You mean you see a three-second pause with the current patch? What's the longest
pause-with-blank-window that you see with this patch?

What's TBE?
Tabbed Browser Extension.  Pretty popular it seems.
Three seconds was the worst. All of these pages are on my local disk so network
latency isn't a factor. These pages normally come up in an instant.

Yes, this is with the patched code.
Attached patch trial patch 3 (obsolete) — Splinter Review
It would helpful if someone who can reproduce this bug can apply this patch to
the trunk and then try to reproduce the bug. I need a log of whatever's output
on the console from the time you start loading the bad page to when the bad
page finally paints.
(In reply to comment #114)
> Created an attachment (id=149669)
> trial patch 3
> 
> It would helpful if someone who can reproduce this bug can apply this patch to
> the trunk and then try to reproduce the bug. I need a log of whatever's output
> on the console from the time you start loading the bad page to when the bad
> page finally paints.

I have a pull running now. Will try the build later this morning.
Some patch application failures. I fixed the first one by hand. The second
one shows a diff but I can't see any difference in it so I left it alone.
Build is running now and should be done in a few hours.

F:\Mozilla\mozilla>patch -p0 < f:\mozilla\mike.patch
patching file view/public/nsIView.h
patching file view/public/nsIViewManager.h
patching file view/src/nsView.cpp
patching file view/src/nsViewManager.cpp
patching file view/src/nsViewManager.h
Hunk #2 FAILED at 346.
1 out of 3 hunks FAILED -- saving rejects to file view/src/nsViewManager.h.rej
patching file content/base/src/nsContentSink.cpp
patching file content/base/src/nsDocumentViewer.cpp
patching file content/base/src/nsPrintEngine.cpp
patching file content/html/content/public/Makefile.in
Hunk #1 FAILED at 44.
1 out of 1 hunk FAILED -- saving rejects to file content/html/content/public/Makefile.in.rej
patching file layout/html/base/src/nsContainerFrame.cpp
patching file layout/html/base/src/nsObjectFrame.cpp
patching file layout/html/base/src/nsPresShell.cpp
patching file layout/html/document/src/nsFrameSetFrame.cpp
patching file layout/html/style/src/nsCSSFrameConstructor.cpp
patching file layout/html/style/src/nsCSSRendering.cpp
patching file layout/html/tests/table/TableContentTest/TableContentTest.cpp
patching file layout/xul/base/src/nsMenuPopupFrame.cpp
That patch is unfortunately incomplete, because I suck and made a mistake. I
think your build will fail. I'll attach the full patch (updated to trunk so
hopefully no rejects).
Attached patch trial patch 4Splinter Review
Terribly sorry about that.
Attachment #149669 - Attachment is obsolete: true
It did fail on a compile somewhere. Just got back from sports and shopping. Will give it another try.
This was with a fresh cvs pull around 6 PM EST:

F:\Mozilla\mozilla>patch -p0 < f:\mozilla\mike.patch
patching file view/public/nsIView.h
patching file view/public/nsIViewManager.h
patching file view/src/nsView.cpp
patching file view/src/nsViewManager.cpp
Hunk #6 succeeded at 3075 (offset 10 lines).
Hunk #7 succeeded at 3925 (offset 10 lines).
patching file view/src/nsViewManager.h
Hunk #2 FAILED at 346.
1 out of 3 hunks FAILED -- saving rejects to file view/src/nsViewManager.h.rej
patching file content/base/src/nsContentSink.cpp
Hunk #1 succeeded at 971 (offset -4 lines).
patching file content/base/src/nsDocumentViewer.cpp
patching file content/base/src/nsPrintEngine.cpp
patching file layout/html/base/src/nsContainerFrame.cpp
patching file layout/html/base/src/nsObjectFrame.cpp
patching file layout/html/base/src/nsPresShell.cpp
Hunk #3 succeeded at 4896 (offset 3 lines).
Hunk #4 succeeded at 5816 (offset 3 lines).
Hunk #5 succeeded at 6443 (offset 3 lines).
Hunk #6 succeeded at 7030 (offset 3 lines).
patching file layout/html/document/src/nsFrameSetFrame.cpp
patching file layout/html/style/src/nsCSSFrameConstructor.cpp
patching file layout/html/style/src/nsCSSRendering.cpp
patching file layout/html/tests/table/TableContentTest/TableContentTest.cpp
patching file layout/xul/base/src/nsMenuPopupFrame.cpp
patching file accessible/src/base/nsCaretAccessible.cpp
patching file accessible/src/base/nsDocAccessible.cpp
Hunk #1 succeeded at 436 (offset 17 lines).
patching file docshell/base/nsDocShell.cpp
patching file dom/src/base/nsGlobalWindow.cpp
Hunk #1 succeeded at 4313 (offset 37 lines).
Hunk #2 succeeded at 4335 (offset 37 lines).
Hunk #3 succeeded at 4362 (offset 37 lines).
Hunk #4 succeeded at 5703 (offset 37 lines).
patching file editor/libeditor/text/nsEditorEventListeners.cpp
patching file extensions/inspector/base/src/inLayoutUtils.cpp
patching file extensions/layout-debug/src/nsLayoutDebuggingTools.cpp
patching file webshell/tests/viewer/nsBrowserWindow.cpp
patching file webshell/tests/viewer/nsXPBaseWindow.cpp
patching file widget/src/xpwidgets/nsBaseFilePicker.cpp
I first encountered this bug with a build from 2004-05-13, in MailNews (see my
duplicate bug 243924). Now I am using build 2004-06-02-08 , and am only seeing
the bug with 'view source',  not in MailNews.
(In reply to comment #121)
> Any news?

See the post before yours. The patch lok is there and I had a bunch of things
to do last weekend so I thought that you'd take a look at it. I still have 
the environment around so I can still play around with it if need be.
The patch applied except for one reject from nsViewManager.h which I assume is
the same one as before. It should be easy to fix by hand the same way you did
last time.
(In reply to comment #124)
> The patch applied except for one reject from nsViewManager.h which I assume is
> the same one as before. It should be easy to fix by hand the same way you did
> last time.

I'll have a look in a bit. I have a new 64-bit laptop running Windows-64 and I'm
trying to figure out how to do a native FireFox build for it.
FWIW, as with comment 122 - I can no longer reproduce this bug in the browser at
Google (or any other site I've tried) with the 6/05-07 build under XP.
I know this is fixed because I backed out the change that caused it.

What we are trying to determine now is *why* that change caused this bug, so I
can rework the change and land it again without causing this bug to reappear.
Michael is generously helping me with that.
> I backed out the change that caused it.

Argh!  Somehow I missed comment 67.  However, if this bug is now completely
resolved, it should be marked as FIXED and work/testing should continue in bug
233441.  (I've never seen a fixed bug remaining open before...) If view source
(as per comment 122) is to be treated separately, then this bug should still be
resolved as FIXED and view source can be picked up in bug 243195 specifically.

In any case, I'm not sure why this is remaining open at this point, unless
there's still something other than view source that's currently broken?
The problem is still there though it's a little harder to reproduce now. This
could also be interpreted as that the process is a little quicker than before.

I still see a flicker about 25% of the time and a pause of about 2 seconds or 
less about 10% of the time.

Are you located in the NorthEast?
> The problem is still there though it's a little harder to reproduce now.

Okay, so *just* backing out the patch for 233441 was insufficient.  Something
else is still breaking functionality.  Working on ways of "fixing" that patch
aren't going to provide a final solution here.  Has anybody managed to locate
another component, in addition to that patch, that contributed?

I'm no longer able to see the problem with the latest build.  Can you provide a
new test case where I can reproduce the problem?  (Just going to google.com no
longer shows me anything unusual.)

> Are you located in the NorthEast?

Burlington, Ontario (an hour West of Toronto).
The problem is NOT in the current code base. I'm just testing patches that
I think are trying to solve another problem.

(In reply to comment #130)
> > The problem is still there though it's a little harder to reproduce now.
> 
> Okay, so *just* backing out the patch for 233441 was insufficient.  Something
> else is still breaking functionality.  Working on ways of "fixing" that patch
> aren't going to provide a final solution here.  Has anybody managed to locate
> another component, in addition to that patch, that contributed?
> 
> I'm no longer able to see the problem with the latest build.  Can you provide a
> new test case where I can reproduce the problem?  (Just going to google.com no
> longer shows me anything unusual.)
> 
> > Are you located in the NorthEast?
> 
> Burlington, Ontario (an hour West of Toronto).

> The problem is NOT in the current code base. I'm just testing patches that
> I think are trying to solve another problem.

Okay, then let me be clear.  If the problem does not exist in the current
Mozilla builds, then this bug should be resolved as FIXED.  Testing of patches
for a different bug (233441) should take place in that other bug.

Unless somebody can tell me how to reproduce the original problem in the current
builds, then this bug should be resolved since the fix has already been
implemented (backing out the other patch).
I think that you need to work that out with roc as far as the administrative
stuff goes.

(In reply to comment #132)
> > The problem is NOT in the current code base. I'm just testing patches that
> > I think are trying to solve another problem.
> 
> Okay, then let me be clear.  If the problem does not exist in the current
> Mozilla builds, then this bug should be resolved as FIXED.  Testing of patches
> for a different bug (233441) should take place in that other bug.
> 
> Unless somebody can tell me how to reproduce the original problem in the current
> builds, then this bug should be resolved since the fix has already been
> implemented (backing out the other patch).

alright, let's mark this FIXED. But I still want to discuss the issues with the
patch here, because this is where all the relevant discussion already is. If you
don't like that, just unCC yourself.

Michael: what I need is a log of the output from the console when you run this
patch and see the delayed rendering problem. Preferably, just run the browser
until you load a page and the problem appears, then don't touch the browser and
show me the console output.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
There was a flicker in here. I didn't see the pause problem but a few flickers.
One problem with debugging this way is that there is quite a bit of output onto
the console and that this may be skewing the browser behaviour.

Init'ed PresShell with 02620948 at 37103736
Handling invalidate event for 02620948 at 37113750 (enable refresh)
Starting screen update for 015D7798 of 0,0,1081,1134 at 37193865
Completed screen update for 015D7798 at 37213894
Starting screen update for 015D7798 of 0,0,251,26 at 37223908
Completed screen update for 015D7798 at 37223908
Handling invalidate event for 015D7798 at 37233923
Unsuppressing painting on 02620948 at 37243937
Posting invalidate event for 015D7798 at 37324052
Handling invalidate event for 015D7798 at 37354096
Starting screen update for 015D7798 of 0,0,1081,1132 at 37354096
Completed screen update for 015D7798 at 37374124
Starting screen update for 015D7798 of 0,0,16,16 at 37374124
Completed screen update for 015D7798 at 37374124
Starting screen update for 015D7798 of 0,0,251,26 at 37374124
Completed screen update for 015D7798 at 37374124
Starting screen update for 02620948 of 0,0,1081,1002 at 37374124
Completed screen update for 02620948 at 37394153
Starting screen update for 02464298 of 0,0,1081,1002 at 37394153
Handling invalidate event for 015D7798 at 37394153 (enable refresh)
Starting screen update for 015D7798 of 212,31,348,14 at 37394153
Completed screen update for 015D7798 at 37404168
Starting screen update for 015D7798 of 0,0,16,16 at 37404168
Completed screen update for 015D7798 at 37404168
Starting screen update for 02620948 of 0,0,1081,1002 at 37454240
Completed screen update for 02620948 at 37464254
Posting invalidate event for 015D7798 at 37464254
Handling invalidate event for 015D7798 at 37464254
Starting screen update for 015D7798 of 0,1112,1081,22 at 37474268
Completed screen update for 015D7798 at 37474268
Starting screen update for 015D7798 of 0,23,33,31 at 40198185
Completed screen update for 015D7798 at 40208200
Posting invalidate event for 015D7798 at 40218214
Handling invalidate event for 015D7798 at 40228228
Starting screen update for 015D7798 of 3,55,85,25 at 40228228
Completed screen update for 015D7798 at 40228228
Posting invalidate event for 015D7798 at 40268286
Handling invalidate event for 015D7798 at 40268286
Handling invalidate event for 015D7798 at 40278300
Starting screen update for 015D7798 of 3,55,85,25 at 40278300
Completed screen update for 015D7798 at 40288315
Starting screen update for 015D7798 of 0,0,251,26 at 40288315
Completed screen update for 015D7798 at 40288315
Sifting through the comments i cannot seem to get the definite answer: does this
bug or does it not cause flickering in web pages?

I'm asking because after the patch has been backed out [using Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040609] i still see heavy
flickering on for instance http://www.gamespot.com/xbox/index.html
Patrick, this bug isn't really a flickering, but a long delay with a blank page
while loading.  The Gamespot issue ultimately resolves to bug 132337 (by way of
bug 242109).
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.