Closed Bug 242856 Opened 21 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.

Attachment

General

Created:
Updated:
Size: