Closed Bug 55938 Opened 24 years ago Closed 22 years ago

Doesn't render all the text on pages

Categories

(Core :: Networking, defect, P4)

Product:
Core
Component:
Networking
Platform:
DEC
OSF/1
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: kk, Assigned: neeti)

References

(
URL
)

Details

(Keywords: helpwanted) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OSF1 V4.0 alpha; en-US; m17) Gecko/20000810
BuildID:    20000081018

Mozilla doesn't render all the text on the page when it is first loaded. If I
hit "Reload", the whole text is shown.

Reproducible: Sometimes
Steps to Reproduce:
1. Go to the URL
2. Wait untill "Document: Done" is shown.

Actual Results:  Just the first line or so of the document body is shown (body
in this context doesn't mean contents of HTML element BODY, but the body of the
article on this newspaper site). When I look at the code, it might look as if it
hasn't loaded the entire document, but when I hit reload, it displays very fast,
so it is unlikely that it hasn't loaded the document.

Expected Results:  The expected result is what happens when you hit reload, you
see the whole text.

It seems to happen on most of the pages on this site, not only the given URL. I
haven't been able to come up with a minimal example.
Ah, I just come to think of the log that Mozilla makes. I had it redriected to a
file.
I click on a link from the page at http://www.vg.no/ and it goes:
WEBSHELL- = 12
WEBSHELL- = 11
WEBSHELL- = 10
WEBSHELL- = 9
WEBSHELL- = 8
WEBSHELL- = 7
WEBSHELL+ = 8
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
Document: Done (2.063 secs)
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
Document http://www.vg.no/pub/vgart.hbs?artid=9620239 loaded successfully

But it doesn't show in it's entirety. Then, I hit reload, and it goes:
WEBSHELL- = 7
WEBSHELL+ = 8
WEBSHELL+ = 9
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
Document: Done (8.993 secs)
*** check number of frames in content area
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
Document http://www.vg.no/pub/vgart.hbs?artid=9620239 loaded successfully

OK, so it takes some time. Either that's due to an image that wasn't loaded at
first, or my hypothesis that it had been loaded in it's entirety that I
forwarded in my initial report is false.
Summary: Doesn't render all the text on page → Doesn't render all the text on page
could oyu get a new build? m18 will be coming soon
this page loads fine in linux, win32 and mac mozilla trunk builds from 10/10.
Over to Layout.
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen
I just downloaded m18, running it on an alphaev56 with osf5 (the build didn't
run on alphaev6 osf4.2, but it didn't say it would), and I'm sorry to report
that the problem persists. My Build ID is 2000101321.
setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please triage.
Assignee: clayton → joki
This happens to me on a wide range of sites, and with pictures too! The
'minimal' case is the mozilla homepage (!) which consistently refuses to display
the last line with the download links under Nightly Builds. Quite a lot of pages
break off somewhere in the middle. 

Sometimes the breakoff happens earlier. Another example is the NY Times homepage
were the first headline (which is a picture) and the picture more often than not
is not, or only half displayed

I suspect (as a first hunch) there is some problem with the picture rendering
library/threading that causes the page download to break off when there is a
delay, since pages that do not have pictures do not seem to exhibit this problem
(but I have not tested this extensively). 

I have observed this problem only on the Tru64 5.0 and 5.1, both with M17 and
M18, and I have been running Mozilla on 386/Linux, Windows NT and Windows 98.

This is bug is currently a killer, because it makes Mozilla completely unusable
(there is no indication that only half the page is downloaded, which can cause a
lot of confusion and problems)
Interesting comment!

I've had a hunch for some time that it has to do with forms... I'm having
trouble on Slashdot, for example, once I was previewing a comment I was about to
submit, I had misspelled </blockquote>, thus leaving it open, everything was
fine down to when the form for comments, reappeared, well, it didn't appear...
:-) I haven't seen this problem on a validating page, though. It is pretty bad,
yes, perhaps I shouldn't have marked it minor. Well, we're throwing you in all
directions here... :-)
This bug hasn't been well narrowed down yet.  The basic issue seems to be 
incomplete rendering of a page.  It may or may not have to do with images 
loading.  I may or may not have to do with valid pages.  I going to reassign to 
a layout guy who might be able to track this via rendering.
Assignee: joki → buster
Summary: Doesn't render all the text on page → Doesn't render all the text on pages
Is this a dup of bug 57679?
I just downloaded 0.7, build id 2001011010, and the problem is still there, but
may not show up quite as frequently as it did. I can't tell if this observation
is significant, though.
I very strongly doubt this is a layout problem.  It is specific to OSF/1, and we
have no resources to debug that platform.  If you can render a local copy of the
page properly, or if hitting reload causes the page to load properly, then it's
probably a networking bug and not a layout bug.
Keywords: helpwanted
Priority: P3 → P4
I've just downloaded and ran 0.9 with Build ID 2001050809, and I'm pleased to
report that I have failed to reproduce the problems I have previously reported,
using this build.

I have surfed a few pages, and pages were this appeared consistently now renders
perfectly. I hope this means that the bug has been resolved, but of course I
cannot be completely sure it has. 
Hm... In 0.9 I didn't see this bug ever, but in 0.9.2, I think I saw it
sometimes, but I couldn't be really sure. BTW, I have used Mozilla more
extensively after the 9.2 release, as I found this release to be more stable
than Netscape 4.77. Consequently, I would have more opportunity to discover bugs. 
But now, in 0.9.3, I'm pretty sure it's back... :-( 
All along, I've been using the builds provided on the Mozilla download-page for
osf/1 v4.0. 

I really have no idea if this is a layout problem or a networking problem or
whatever. If Netscape engineers feels the component designation is wrong, please
do change it.
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
I guess it is unlikely that this is a layout problem, since I've been able to
download pages by wget and have them rendered perfectly, while the page still
has problems when downloaded by Mozilla.

Thus, I have taken buster's advice and changed the component. Hope that's ok.
Component: Layout → Networking
Reassigning to owner of networking component since the user reports that
downloading the pages using wget fixes the problem.
Assignee: attinasi → neeti
QA Contact: petersen → benc
Target Milestone: --- → Future
Kjetil: are you still seeing this with recent builds (Linux-Alpha seems to work ok)?
I have tested this over a couple of days with Build ID 2002031814, which was the
most recent build for my OS, and I have not been able to reproduce the problem.

(However, Mozilla crashes as it starts to prompt me about a Flash plugin, but
that is likely to be completely unrelated)
ok.  marking WORKSFORME.

feel free to reopen if you see this again.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.