Closed
Bug 55938
Opened 24 years ago
Closed 22 years ago
Doesn't render all the text on pages
Categories
(Core :: Networking, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: kk, Assigned: neeti)
References
()
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.
Reporter | ||
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
could oyu get a new build? m18 will be coming soon
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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.
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)
Reporter | ||
Comment 8•24 years ago
|
||
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... :-)
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
Is this a dup of bug 57679?
Reporter | ||
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
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
Reporter | ||
Comment 13•23 years ago
|
||
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.
Reporter | ||
Comment 14•23 years ago
|
||
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.
Reporter | ||
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
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
Comment 18•22 years ago
|
||
Kjetil: are you still seeing this with recent builds (Linux-Alpha seems to work ok)?
Reporter | ||
Comment 19•22 years ago
|
||
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)
Comment 20•22 years ago
|
||
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.
Description
•