Closed Bug 77634 Opened 23 years ago Closed 23 years ago

Many pages not rendering

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: jg, Assigned: gagan)

References

(
URL
)

Details

(Keywords: smoketest)

Attachments

(2 files)

Rendering of google.co.uk following hyatt's patch
31.11 KB, image/png
Details
Rendering of Bug attachment upload form
35.47 KB, image/png
Details 
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.
Keywords: smoketest

    
    

    
  
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.

Status: NEW → ASSIGNED

    
    

    
  
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].
Severity: blocker → major

    
    

    
  
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.

Keywords: qawanted

    
    

    
  
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.

Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
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.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
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.

Status: REOPENED → ASSIGNED

    
    

    
  
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*.

OS: Linux → All

    
    

    
  
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.

Assignee: hyatt → gagan
Status: ASSIGNED → NEW

    
    

    
  
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.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
I've tested the URLs and some of the DUPs on Linux 2001062021. Marking verified WFM.
Status: RESOLVED → VERIFIED

    
  
Keywords: qawanted

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: