Built following hyatt's checkin for bug 77002, my linux build isn't rendering a number of URLs reliably: http://google.co.uk http://mozilla.org probably many others Either no rendering is done, or it is partial. Assigning to hyatt since it worked fine before his checkin. I'm on a K6-2 300 with 256Mb ram if that is relevant.

both of these urls work fine for me, as does everything else ive tried so far. (build 2001042514 on x86 linux)

Works for me on 2001-04-25-14 Linux RedHat 7.1 P3 600Mhz high-speed internet connection.

Finding the logo on yahoo.com & sometimes the small ad at the top not being rendered when loading from cache. not sure if its the same bug for not.

The yahoo logo and, in general, the occasional failure to draw an image predate hyatt's checkin. However, there is a problem with the paint suppression timeout, and hyatt is looking into this.

This is occurring frequently, if also a little randomly, on hitting back, with cached content.

I just hit the link for "View Bug Activity" on this very page, and got very little of the result rendered. I had to minimize then restore the window to get the page rendered.

Also, in the pref diaglog, for example clicking 'Fonts' in the Modern skin, the initial background is gray before the content gets display. Prior to the patch, the background was white and this was matching with the general appearance of the skin. The added transient gray background seems to come from nowhere and doesn't make things look quite smooth.

I've noticed that www.mozilla.org is coming over the network instead of the cache when I back-and-forward between www.kernel.org and www.mozilla.org. I don't know if that's relevant, but there ya are. (n.b. I only started noticing it with hyatt's patch.)

The patch was tested by several Linux users, and they didn't see this. I'm going to wait to see if our verifiers find this to be a problem as well. If they don't see it, IMO this should be downgraded from smoketest status. The Win32 timer issue has been filed as 77653.

Also, rbs, I have working on my machine a patch that keeps the old page around until the new one is ready to go. I'll be posting that shortly to a new bug.

I've tested the linux build (2001-04-25-15-trunk/) with a normal LAN connection to the Internet, and by running this through a throttling proxy server that I have (which emulates a 56K connection as best it can). I did not see an instance of pages not properly painting, including on google.co.uk, bugzilla attachments, bugzilla view activity, mozilla.org, yahoo.com, netscape.com and various other pages. I'm not saying that there isn't a problem, but I'm dropping the priority to major from blocker, since it wouldn't be reasonable to hold the tree closed for something that is not easily reproducible. (Side note: I checked back/forward behaviour between mozilla and kernel.org (and others) by reviewing the proxy logs. I do not do a GET to the network when doing back/forward. adam: how we're you able to confirm that you were going to the network in this case [although side-side-note: this isn't this bug, since hyatt's changes do not (or shouldn't) make any change to the caching logic].

OK I just updated my optimised build to the tip. A side note to this is that libpr0n failed to built, I had to blast away gfx2/ and modules/libpr0n from both my source dir and object dir, it compiles fine now. I have also blasted away dist/bin/component.reg. The problem is still occurring. Many pages either fail to render at all or render small areas. The effect, from what I can tell by looking at my cpu meter and also reneral responsiveness, is that mozilla doesn't actually attempt to do rendering. It's like it quits trying the render the page immediately, or at least far too soon. On google.co.uk, I am often getting a blank, white page, with just the cursor blinking. No frame for the input element, no logo, no other text. As soon as I hit a key, the form appears. If I then right-click over part of the page where content should be shown, and then dismiss the pop-up menu, that area of the page is correct invalidated and content is drawn, but the rest of the page is still left blank. This problem does not affect all pages. For example, I tried netscape.com and news.com and both rendered fine. I'm going to download the latest linux nightly and try that, see if we can eliminate my local build from the cause.

OK I have the solution. The latest nightly has this problem too, so I blew away ~/.mozilla and restarted. Both the latest nightly and my local build work fine now. I'm marking this a WFM *sigh* - if any of you still have problems with this or feel that blowing away the .mozilla directory should not be neccessary, feel free to reopen.

i move we reopen this bug. (i don't have sufficient permissions to do so... i don't think!) several pages are still not rendering for me (x86/Linux, Build 2001042608) after hyatt's landing. specifically, http://www.rice.edu and http://www.uky.edu are missing part or all of the images on the home page; forcing it to paint requires dragging the window off-screen and (slowly) back on. minimizing and maximizing doesn't work. if no, i'll file a separate bug.

Nothing i did would affect profiles. Perhaps the cache is getting corrupted? If so, that would be unrelated to my checkin.

Reopening bug. www.rice.edu renders fine. www.uky.edu has missing images that appear when you hover over them. Minimise the browser then restore the window and huge chunks of the page go missing. Hyatt: I can't think that this is cache-related since I blew my NewCache/ and Cache/ dirs away last night while testing, and it did not resolve the problem. Only when I blew away the entire profile directory (.mozilla/) and restart did sites like google.co.uk work again. The problems on www.uky.edu could conceivably be a seperate bug in libpr0n, however I couldn't be certain myself, so I'm cc'ing pavlov who might want to identify it. Pavlov: if you can tell us that the prohlems Brian is seeing is libpr0n related please let us know, and we'll once again mark this as resolved, otherwise this one will remain open until more information comes to light.

Oops, really cc pavlov. Pav, please take a look at the comments I just made and act as appropriate.

btw, forgot that bit...nuking ~/.mozilla doesn't help matters.

someone smack me over the head if i should open a separate bug for this. i'm seeing painting problems in the "Privacy and Security" prefs panel as well. The text boxes seem to almostt paint over the three buttons on that panel; floating a window over them resolves the problem.

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

*smack* :-] Known problem - bug 75402.

I don't know if this may be relevant, but I have noticed an odd behaviour visiting http://news.com/ both in going to it first time, and hitting back to go to it: On the first occassion (not cached), the background was painted in solid purple, then white and content got painted returning it to normality. On the second occassion (cached, hitting back), the initial background paint was of green. The white background and content once again came through and all was normal. Very odd.

Perhaps, that is bug 77507 - flashing background in random color

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

Not sure what to do with this. I believe it's a problem, but I can't reproduce on any platform. jrgm saw no problems on win32, mac, or linux, running the page load tests. I'm ok on Win98 and Win2k. Pink is running fine on Mac. danm is running on linux with no problems.

I'm spinning up a Win32 debug build on my laptop where I see this. More in a couple hours if I can repro under the debugger.

OS/All. It seems to be a fairly random problem. google.co.uk has worked fine for me since I cleared .mozilla/. I hypothesize that you are more likely to see it on a slow machine loading a webpage that causes a relatively low number of reflows or that renders relatively quickly (which would depend on the "timer" code being tuned and correct, right?). Just a thought *shrug*.

I think I have figured this out on Linux anyway. I had turned off the new view manger several weeks back in my prefs.js with user_pref("nglayout.debug.enable_scary_view_manager", false); Get rid of that line, and all pages render fine. Put it back in, and the bug reappears. Tested it twice to be sure. Thats why removing .mozilla works as well.

Tried that pref on WinNT and it didn't help. My debug build is still going.

wish i could verify. i still see the bug with a brand-new Default profile

hyatt, do you have the bug number as per your you comments of "2001-04-25 20:05" I would like to see if there is any dependence with bug 77507 - flashing background in random color.

phil deleted his cache folder and the problem went away. This appears to be a cache issue. Reassigning.

This is certainly a pseudorandom bug. I think I've seen it 5 times in the last two months (of nearly constant use of the browser :-) but it has been a different site each time. I blow away my .mozilla directory on a regular basis, and I'm using linux. It happened to me just an hour ago (on http://www.tigris.org -- but I don't think that really matters) and I decided to see how many times I had to click "reload" to get it to desiplay properly. I reloaded the page about a dozen times, and still saw a complete blank. I decided to view the source, which displayed correctly...then I reloaded the page and it rendered nicely. I repeated this experience about a half an hour later. Somehow viewing the source triggers something that makes the pages display. Hopefully someone else tracking this bug will be able to reproduce?

excuse the noise. are we still talking about *whole pages* not rendering, as per the summary? or parts of pages? or images? i'm still having image problems on www.uky.edu...but if this is the wrong bug, i'll be happy to go away. (= i can also verify pohl's problem with www.tigris.org, as well as the problem leaving when i hit "view source." i can't reproduce it if i blow away my .mozilla directory (which i am loath to do, anyway.) however, if i hit the "clear" buttons for both caches (memory and disk), then go back to the page, the problems reasserts itself. the background remains gray, like what happens when you pass Mozilla an empty file. as if gecko doesn't have anything *to* render.

update: i agree that pohl's is a cache issue. i saved the HTML to a file, and *it* renders just fine. i can attach it, if you'd like, or you can get it yourself. (=

Cool! I can verify that using the cache-clear buttons in the preferences panel makes the problem come back. That was a useful observation. Using this ability to reproduce the problem, I decided to check if SaveAs would tickle the same magic spot that View Source does -- and, indeed, when I reload after saving the page renders just fine. FWIW, I'm talking about whole pages not displaying. I consider the image rendering problem to be a separate issue, probably related to libpr0n?

This bug was initially filed to note some apparent difficulties with displaying documents after a checkin by hyatt to suppress painting temporarily while loading. Subsequently, a number of unrelated behaviours were noted, including: o failure to load and/or correctly display images (many bugs on file) o failure to pull pages out of the cache on back/forward (can't reproduce?) o layout problems in the 'Privacy and Security' panel (bug 75402) o what some people were seeing was with the old view manager o apparently some people get relief by deleting their cache directory Heh. This is the point where bugs begin to go off the rails, and even worthwhile observations (like about tigris.org) can get lost because no one is sure what the bug is about anymore (is this a painting bug? a layout bug? a cache bug? something else?). I've filed bug 78313, specifically to cover the problem in loading tigris.org. That is clearly either HTTP or cache (or both) [the document gets truncated at some point]. Maybe gagan wants to hang on to this bug for investigating a general problem with cache corruption. Up to him if it stays open on that point.

I am seeing exactly the same behaviour (whole page not rendering at all) on the http://gcc.gnu.org/ page (I've reported it in the bug 78168). Please look at the comments on that bug.

I started seeing this problem with some XML (MathML) pages and got puzzled about it. iF I visit http://www.mozilla.org/projects/mathml/start.xml with m0.9, it does render. But if I visit it with a build from the m0.9.1 trunk, it doesn't render. Could you folks who are seeing pages that are not rendered try the following: - visit the page that is not rendered while leaving the browser window slightly covered by some other window on your desktop - then when rendering seems to stall, click to give focus to the browser window and to bring it on the foreground. If with this the page now re-appears fully, then that would mean that it isn't a cache issue. With the XML (MathML) situation I described above, I am seeing that bringing the browser window to the foreground causes the page to render fully.

the recent view manager changes are causing a lot of things not to render.

Verified on build: 2001-05-14-04-Trunk platform: WinNT I am not crashing on any of the following url's: http://www.google.co.uk/ http://mozilla.org http://gcc.gnu.org All the pages are rendered properly. Also, they were rendered properly when I clicked on 'Back' and 'forward' button. I deleted the cache and then loaded all three pages and hit 'Back' and 'forward' button. The pages were rendered ok all the time.

Making it as WFM.

I've tested the URLs and some of the DUPs on Linux 2001062021. Marking verified WFM.