mozilla hangs on loading large files

VERIFIED WORKSFORME

Status

()

Core
Layout
P3
major
VERIFIED WORKSFORME
18 years ago
9 years ago

People

(Reporter: Hugh Kennedy, Assigned: Kevin McCluskey (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
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.

Comment 1

18 years ago
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.

Updated

18 years ago
Component: Browser-General → Layout
QA Contact: leger → petersen

Comment 2

18 years ago
http://bugzilla.mozilla.org/show_bug.cgi?id=6048 was fixed.  Are you waiting
long enough?  What type of elements are in this page?

Updated

18 years ago
Assignee: leger → troy

Comment 3

18 years ago
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.
(Reporter)

Comment 4

18 years ago
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.

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 5

18 years ago
*** This bug has been marked as a duplicate of 11702 ***

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 6

18 years ago
Marking as verified dup of 11702.
(Reporter)

Updated

18 years ago
Status: VERIFIED → REOPENED
(Reporter)

Comment 7

18 years ago
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.

Updated

18 years ago
Status: REOPENED → ASSIGNED

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago

Comment 8

18 years ago
Bug 11702 has not been marked fixed, so this bug should not be re-opened

Comment 9

18 years ago
*** This bug has been marked as a duplicate of 11702 ***

Comment 10

18 years ago
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.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 11

18 years ago
Agreed. Marking as duplicate of 11702.
(Reporter)

Comment 12

18 years ago
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 → ---

Comment 13

18 years ago
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
(Reporter)

Comment 14

18 years ago
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.

(Assignee)

Comment 15

18 years ago
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
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Updated

18 years ago
Keywords: verifyme

Comment 16

18 years ago
Verified working with yesterdays build on Win98.
Better incremental reflow would be great, though. *sigh*
Status: RESOLVED → VERIFIED

Updated

9 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.