83175 - Only part of a page is loaded/displayed

Status: VERIFIED DUPLICATE of bug 82720

(Core :: Networking: HTTP, defect, P2)

Description

[Martin Macok]

When I start Mozilla and visit "http://www.ceskenoviny.cz/" the page is loaded
only from a half.

Comment 1

[Martin Macok]

Attachment: screenshot of M2001052919 and Netscape4.77 showing www.ceskenoviny.cz

Comment 2

[Kamil Toman]

Confirming this on my 2001052721. System is Linux 2.4.3 Debian Woody.

Comment 3

[Asa Dotzler [:asa]]

Worksforme with 052904 mozilla win32 build on win2K and win98, 052908 mozilla
linux build on RedHat 6.2 and 052908 mozilla mac build on OS 9.1 Please reopen
if you are still seeing this with a current nightly build. Thanks for your help
in testing Mozilla and reporting bugs.

Comment 4

[Chris Hiner]

Might be bug 77634 or bug 78313.

Comment 5

[Martin Macok]

NOT fixed in 2001053019 on Red Hat Linux 7.1.

Comment 6

[timeless]

are you using a proxy?

Comment 7

[Martin Macok]

Yes, that was a shot! When I turned it off and switched to a direct connection
then the page is loaded right.

I'm using squid-2.3.STABLE4-10, should I try a newer one?

Is it a bug in a proxy software, or in a proxy handling routines of Mozilla?

Comment 8

[Martin Macok]

Oh, but when I tried it later (with direct connection) then it's still loading
only from a part like before (through squid proxy). I have tried turning
memory/disk cache off but it didn't help.

Comment 9

[timeless]

sigh your last comment is so annoying ;-)  yes we have some problems w/ 
proxies.  If each new profile w/ no proxy can load the page right the first 
time (a), but the second time (b) you load the page it messes up then let's 
blame cache.  If a similar test fails for proxy (c)(d)then i'd be pretty sure 
it's cache.

otoh if it usually works the second time (b) then i'd blame our proxy support.

if (d) works often then we should probably point our finger at parser or 
layout. Before layout, please check view>source to see if it has the full 
document.

Comment 10

[Martin Macok]

actual state:
2001060219 on Red Hat 7.1

The page at www.ceskenoviny.cz is always loaded only partial (the first part),
even with new profile with proxy and with new profile without proxy. I have
tried to enable/disable disk/mem cache at Preferences/Debug dialog with no
change ...
Sometimes the is even not loaded at all (I click on bookmarks/sidebar on its
bookmark and it's like it's ignored).

Comment 11

[benc]

->new, happens to me + probably dupable.
+qawanted
OS = ALL
I see this, but for the life of me, cannot reporduce it in Mozilla 0.9 for Win32.

Happens w/o proxy for me, when loading bugzilla pages, of all things...

I need to actually look at view source when this happens to me, I'm usually too
engrossed to work on in.

Comment 12

[Martin Macok]

The bug is triggered when switching charsets (manu/view/character coding/).
The default is in UTF-8 and with it the page is not shown whole.
When I switch to iso-8859-1, iso-8859-2, cp-1250 and other charsets (the
characters got messed up of course but) I see the whole page.
Switching back to UTF-8 makes only the first part of the page shown.

(Red Hat Linux 7.1, 2001060219 (latest-0.9.1/pre))

Comment 13

[Tom Mraz]

I see a simmilar behavior - the page loaded only partially - with the
http://www.freeswan.org/

The page loads fine when I reload it.

I use a squid proxy too.

After purging the mem/disk cache it loads only partially again.

M 0.9.1 linux 2001060506

Comment 14

[Martin Macok]

I have see this behavior also with http://google.org/
Type something to search and hit enter. Sometimes (30%) the page is loaded only
partially (just logo and search form, no search results) and I must hit reload
to load the entire page.

Comment 15

[Ivan Brezina]

I have experienced similar behavior in Netscape 4.7x. Our student campus 
is connected via some strange cisco transparent proxy, which causes this 
thinks(creating crypto tunnel between me and my webserver had helped). 
In NN 4.7x it was very rare. In mozilla 0.9.1 it was very often, latest cvs
snapshots seem work better, but they are not so "good in this" as NN 4.7x.

Comment 16

[Dan Rosen]

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

Comment 17

[Dan Rosen]

This is definitely not a proxy bug, and it doesn't have anything to do with
charset either. See attachment 39609 [details] to duped bug 87220:

  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=39609

I'm not using a proxy. Info from duped bug 87220:

> On my CVS build today (21 June) pages randomly only partially load. It seems
> like they don't want to reflow when more content (images, etc.) come in (the
> reason I'm assigning to layout for the moment) but it could just as easily be
> a networking issue, or a problem with hyatt's paint suppression.
>
> The symptom is, basically, pages occasionally show up blank or partially
> loaded. Hitting reload helps, but you might have to hit it a couple times to
> get the page to render completely. I'll attach a screenshot.

...

> I've definitely seen this on Windows.  I can't reliably reproduce though.  I
> think I saw it in mail once too...

...

> Observed this problem with 0.9.1 under Windows 2000 Server.  Sometimes
> required multiple reloads before the page was displayed properly.

FYI, I've seen this on all pages, all over the place. NY Times, Google, others.
MailNews once or twice also (which makes me think it's *not* an HTTP problem).

Comment 18

[kent dorsey]

The following sequence of commands can be used to consistently reproduce this
bug under Windows 2000 Server on one of my machines.  Hope this helps (and works
for others).

1. Start Mozilla (my settings start with a mail window).
2. Clear memory and disk caches.
2.a. Select "Edit / Preferences / Advanced / Cache / Clear Memory Cache"
2.b. Select "Edit / Preferences / Advanced / Cache / Clear Disk Cache"
3. Open a browser window.
Note: Steps 2 and 3 can be reversed; browser can be set to open with blank page
or live web page.
4. Select "Debug / Viewer Demos / #9 Frames" (loads from resource)
5. Select "Debug / XBL Demos / #1 Technicolor DIV" (loads from www.mozilla.org)
6. The page will not completely load.
7. Go to non-www.mozzila.org web site.
8. Repeat step 2 to clear caches.
9. Repeat steps 4 and 5 to reproduce again.

Did not test further for other possibilities.  My cache settings are 4096
memory, 5000 disk, Check every time.

Comment 19

[kent dorsey]

Mozilla 0.9.1 used for previous test case under Windows 2000 Server.

Comment 20

[kent dorsey]

Attachment: partial load window capture

Comment 21

[kent dorsey]

Attachment: re-loaded window capture

Comment 22

[Darin Fisher]

kent: any chance you could repeat your tests using a recent nightly build?

Comment 23

[kent dorsey]

doh! test case no longer reproduces bug in latest nightly build:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+) Gecko/20010627
mozilla-win32-talkback.zip 27-Jun-2001 10:48   9.1M
note to self: verify in latest build next time

Comment 24

[kent dorsey]

double doh! test case DOES WORK in latest 0.9.2 build:
 http://ftp.mozilla.org/pub/mozilla/nightly/2001-06-27-10-0.9.2/mozilla-win32-talkback.zip


Mozilla 0.9.2
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010627

as opposed to:

http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip

used in preceding comment.

Comment 25

[kent dorsey]

Just to clarify my wording, the bug is STILL PRESENT and REPRODUCIBLE in build
2001-06-27-10-0.9.2 under Windows 2000 Server, but is NOT REPRODUCIBLE using the
cited nightly latest.  It's been awhile since I've done any formal QA write-ups,
please excuse the lax wording.

Comment 26

[Darin Fisher]

kent:

interesting, so we just need to examine what was checked into the trunk that was
not checked in on the branch.  can you determine the most recent nightly build
which did exhibit the problem?

Comment 27

[kent dorsey]

darin: mission accomplished (now retiring from testing this bug :)

2001-06-26-06-trunk/mozilla-win32.zip - Build ID: 2001062604 - bug is reproducible

2001-06-26-14-trunk/mozilla-win32.zip - Build ID: 2001062611 - bug is
reproducible (with one anomaly)

2001-06-27-06-trunk/mozilla-win32-talkback.zip Build ID: 2001062704 - bug is no
longer reproducible

note: verified in multiple tests of each build in various orders (working
backward and forward through builds).

anomaly: during the first test of 2001-06-26-14-trunk, the bug was still
reproducible, with the sole difference that the left table (site navigation
links) rendered fully.  during all other tests of this buildand preceding
builds, only the top banner and the first link of the left table (site
navigation links) were rendered, as illustrated in the partial load window
capture attachment.

good luck!

Comment 28

[Tom Mraz]

WOW ! it really seems to be fixed!
I've tried (with Linux 2001062721) the http://www.freeswan.org/
link and it is fine now. Also no problems on google.org and ceskenoviny.

Martin please try it too.

Comment 29

[Martin Macok]

Not sure but it really seems it was fixed sometime during last 2 weeks.
(I have not seen partial load/displayed pages for ~7days)

I have latest pre0.9.1-1 and current CVS version (both WFM).

Comment 30

[kent dorsey]

Shouldn't someone verify that the code changes between the builds I cited
actually map to the underlying cause of this bug to verify that this bug has
been completely fixed?  I.E. let's have some engineering validation on this.

If the codebase were not such a bear and had sufficient architectural
documentation, outsiders such as myself could verify this.  I looked at the
codebase changes yesterday and there seemed to be two relevant candidates that
jumped out, one concerning caching, the other with extract content, but I have
no clue what the code paths are at runtime to simulate, and do not have a
debugging environment set up to trace the two cases on my machine.

Comment 31

[Dan Rosen]

It might WORKFORYOU on the trunk, but helloooo, we've still got a branch to take
care of! Or does nobody give a rat's ass about the 0.9.2 release?

Comment 32

[Martin Macok]

------- Additional Comments From Martin Macok 2001-06-28 05:30 -------
I have latest pre0.9.1-1 and current CVS version (both WFM).

              ^^^^^^^^^^                          ^^^^^^^^


Sorry for my mistake, that was pre0.9.2-1 of course ...

I think it's safe to mark it WFM.

Comment 33

[Dan Rosen]

"pre0.9.2-1" doesn't mean anything to me. Do you see this on the 0.9.2 branch
(MOZILLA_0_9_2_BRANCH)? If you're sure it's not still a bug on the branch, then
you can mark this WFM, otherwise, we still have a problem.

Comment 34

[Martin Macok]

http://ftp.mozilla.org/pub/mozilla/nightly/latest-0.9.2/Red_Hat_7x_RPMS/mozilla-pre0.9.2-1_rh7.i386.rpm

Isn't that MOZILLA_0_9_2_BRANCH?

Comment 35

[Dan Rosen]

I have no idea, I've never used the RPMs.

Comment 36

[kent dorsey]

This bug is still present and reproducible on my setup in the latest 0.9.2
branch Build ID: 2001062803.

Comment 37

[Dan Rosen]

Thank you, Kent. Neeti: Any idea what fixed this on the trunk that hasn't gotten
into the branch? This *needs* to be fixed for the 0.9.2 release, IMHO.

Comment 38

[kent dorsey]

More interesting tidbits: The bug is not always reproducible when using the
Classic theme, but is always reproducible using Modern.

Comment 39

[kent dorsey]

Still present and reproducible in latest 0.9.2 Build ID 2001062903.

Comment 40

[Doug Turner (:dougt)]

this sounds like a dup of 82720 or the other say around.  Moving out milestone. 
Will accept for 0.9.3 if a tested patch is submitted 

Comment 41

[Dan Rosen]

Yep, it's a dup alright.

*** This bug has been marked as a duplicate of 82720 ***

Comment 42

[Tom Mraz]

Verifying based on comments.