Closed Bug 17692 Opened 25 years ago Closed 24 years ago

mozilla hangs on loading large files

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: kennedyh, Assigned: kmcclusk)

References

()

Details

when loading large file to be displayed (not downloaded), using M 10 on WinNT 4
sp 5 (Build ID: 1999100618), mozilla hangs. this is reproducable between
invocations of mozilla.

see the above apache.org mailing list archive (~2.9 Mb) for an example, which
loads fine in navigator 4.5.
Hmm, NN 4.7 estimates 10 minutes. Let's see what Mozilla does given some time.
Status: Contacting, Connecting, Transferring... Lots of modem activity,
then, ~ ten minutes later, lots of swapping and CRASH.

Another attempt. Nothing is showing, but data is definitely transferring.
In the meantime, while pressing the [Stop] button causes it to grey out,
data continues to flow from dev.apache.org, so says the status bar. But
nothing from that site is displaying before or after - this bugzilla page is
still visible. Menus still active before and after [Stop] pressed.

After partially obscuring the window with another and then closing that
window, the obscured region does not repaint. Mozilla does shut down normally.

Another attempt. If the [Back] button is pressed after clicking on the URL
above and letting it start to load, the status bar shows an alternation
between "Transferring data from bugzilla.mozilla.org" (still visible) and
"Transferring data from dev.apache.org" - data continues to flow from
dev.apache.org afterwards. Pressing [Back] again does load the page before
this one (whatever it was), but the data *still* flows from dev.apache.org,
according to the status bar and the modem activity.

This is looking very reminiscent of Bug 16640. May be a DUPLICATE.

Tested with 1999-10-31-08-M11 nightly binary on Win 95.
Component: Browser-General → Layout
QA Contact: leger → petersen
http://bugzilla.mozilla.org/show_bug.cgi?id=6048 was fixed.  Are you waiting
long enough?  What type of elements are in this page?
Assignee: leger → troy
There are no HTML elements at all in the page at the URL above - it is just
a log of mail-list activity, almost 3 megs of plain text.

With the current build, the continued loading after [Stop] or [Back] is still
happening, but pressing [Stop] after a few seconds now does show some content.

Unexpectedly for a file with no extension, there is syntax highlighting in
the mail headers (someone already has a bug open to force text/plain for
files of unknown content-type (NN 4.7 View>Page Info gives the mime-type as
text/plain) - getting that done may change matters here.)

The gfx-scrollbars are also badly messed up, oversize and showing image-loading
proxy icons instead of the correct gfx.

Tested with:
Windows NT 4.0sp3, mozilla.exe, 1999-11-07-08-M11 build.
Its text/plain. It begins rendering immediately in NN 4.5.
How long should I expect to wait to render something with no structure?

I get either intermittent hangs from M10 (pause for 10-30 seconds, run for 5
seconds, repeat. never renders any text), or it will get half the 3 Mb document,
and say Done.  During the hangs there is no window repainting on NT, and the
process memory usage continues to increase until NT runs out of swap (this is on
a 128Mb machine).

The same hanging behavior occurs under M10 on Solaris 2.6 (UltraSPARC).
the apprunner process consumes 98% of the CPU.
truss shows the app is still reading from the network, but the progress is
increadably slow, and nothing is rendered after ~15 minutes.

I can provide a truss or pstack output if it'll help.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 11702 ***
Status: RESOLVED → VERIFIED
Marking as verified dup of 11702.
Status: VERIFIED → REOPENED
This is still buggy in M11 (Build ID: 1999111520) on NT4 sp5.
The page loads partially, but as noted below, despite being text/plain, it does
syntax highlighting.
Now, once the page has loaded (incompletely, but M11 has stopped trying), the
scrollbar behavior is wrong.
the thumb can scroll the page in the window, but the controls at the top and
bottom of the bar no longer move the page at all.
Status: REOPENED → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Bug 11702 has not been marked fixed, so this bug should not be re-opened
*** This bug has been marked as a duplicate of 11702 ***
The syntax highlighting seen with M11 is almost certainly due to the problem
noted in bug 17750 (FIXED in M12) - text/plain was getting treated as HTML
source.

Tested the URL above with 1999-11-19-09-M12 nightly binary on Windows NT,
no highlighting seen.
Status: RESOLVED → VERIFIED
Agreed. Marking as duplicate of 11702.
11702 has been marked verified fixed, but this problem still exists.



it may be a dup of 10736, but the inability to load large files is _very_ real.

The URL referenced above is an HTML 2 document aboot 1 Mb in size.



The following document is a 3 Meg text/plain archive



http://dev.apache.org/mail/new-httpd/new-httpd.200001



both began to display _immediately_ in NN 4.x on solaris/linux/NT, and

burnt all available CPU on M13 for both solaris 2.6 and linux (i386).



Status: VERIFIED → REOPENED
OS: Windows NT → All
Hardware: PC → All
Resolution: DUPLICATE → ---
I don't understand why this was re-opened. Using the latest build it starts to 
display immediately for me. I'm on NT, so maybe there's a Unix specific problem?

Reassigning to Kevin to evaluate from a Unix perspective
Assignee: troy → kmcclusk
Status: REOPENED → NEW
the www.engin URL does load immediately for me using M13 on NT.

the dev.apache URL still hangs mozilla with it burning all availiable CPU on
NT/Solaris/Linux.

Tried loading both http://www.engin.umich.edu/stats/2000-01.html and 
http://www.engin.umich.edu/stats/2000-01.html with a 2/21/2000 build of mozilla 
on Linux and it did not hang and it displayed immediately in both cases. Marking 
as WORKSFORME. 
Status: NEW → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
Keywords: verifyme
Verified working with yesterdays build on Win98.
Better incremental reflow would be great, though. *sigh*
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.