I am trying to load an html file containing a simple (no proprietary or non-standard tags) table that contains 2000 rows X 6 columns. Attempting to load this file results in one of two things: 1. Can take upto 60 mins. to load this table! Pegs CPU and harddrive is quite busy. 2. The browser will never render the table but will eventually crash Netscape. Under Solaris the process just dies and Netscape window disappears. Under NT, get "Virtual memory exhausted" dialog system message FYI: Loading this html file/table under IE 4.0 is FAST with no problems... I can send you the html file if you would like it. Thanks! Occurs in: WinNT, Win98 Netscape Communincator/Nav v4.0 Solaris 2.6 Netscape Communicatior 4.5

Rick, here's one for you if you are willing.

I don't mind taking these when I switch over (approx 2 weeks). But let's keep them on your plate until I can make the switch.

Just to note: The 60 min load was reported against Nav4.x (is that correct mss@eroch.mc.xerox.com? Nav4.0 & Nav4.5 / NT,98,Solaris) I did load this file (win95) in about three minutes a couple of days ago, while IE5 took ~55sec. However, after loading I had a _lot_ of 'video noise' on the viewer canvas. So, not quite there, but a great improvement over Nav4!

To answer question: the 60 min load was recorded using the following: WinNT - Navigator 4.0 Solaris - Communicator 4.5 Win95 - Navigator 4.04 I also received email from Netscape Tech Support stating that: "Netscapes's table rendering code in the past has been notoriously slow. In newer versions there have been some improvements, however until Communicator 5.0 comes out it will still be slow."

I tried to view the attachment and it was garbage. Moving to M11.

This behavior still takes place using the 8.16.99 AM daily build on Mac OS. For an example, please see http://slip/projects/marvin/copy-paste/copy-large-text/ longpage.html (a 2 MB table from Bugzilla.) Try HRL01KTS for a Talkback example. This bug currently blocks the execution of the copy-large-text test case; I'll rewrite the test case in the interim to avoid the use of tables.

Moving to M13.

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

It would be nice if someone could un-gzip the attachment because winzip can't handle it. Warren, I'm crashing (after a long while) when using Viewer and trying to view http://slip/projects/marvin/copy-paste/copy-large-text/longtablepage.html The size of tables has been reduced significantly over the last few months. Please reassing back to me when the crash is fixed. memcpy(unsigned char * 0x00000000, unsigned char * 0x00d35c20, unsigned long 8192) line 171 nsStorageStream::Write(nsStorageStream * const 0x01c0eba4, const char * 0x00d35c20, unsigned int 8192, unsigned int * 0x0012fcdc) line 167 + 20 bytes MemCacheWriteStreamWrapper::Write(MemCacheWriteStreamWrapper * const 0x01c040d0, const char * 0x00d35c20, unsigned int 8192, unsigned int * 0x0012fcdc) line 285 + 38 bytes CacheOutputStream::Write(CacheOutputStream * const 0x01c04090, const char * 0x00d35c20, unsigned int 8192, unsigned int * 0x0012fcdc) line 75 + 38 bytes InterceptStreamListener::write(char * 0x00d35c20, unsigned int 8192) line 1141 InterceptStreamListener::Read(InterceptStreamListener * const 0x01c05ed4, char * 0x00d35c20, unsigned int 8192, unsigned int * 0x0012fdcc) line 1128 + 21 bytes nsParser::OnDataAvailable(nsParser * const 0x01c06634, nsIChannel * 0x01c0a240, nsISupports * 0x00000000, nsIInputStream * 0x01c05ed4, unsigned int 0, unsigned int 8192) line 1299 + 30 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x01c0d2d0, nsIChannel * 0x01c0a240, nsISupports * 0x00000000, nsIInputStream * 0x01c05ed4, unsigned int 0, unsigned int 8192) line 235 + 46 bytes InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 0x01c05ed0, nsIChannel * 0x01c0a240, nsISupports * 0x00000000, nsIInputStream * 0x01c0a768, unsigned int 0, unsigned int 8192) line 1113 nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const 0x01c09030, nsIChannel * 0x01c0e6a4, nsISupports * 0x01c0a240, nsIInputStream * 0x01c0a768, unsigned int 1056768, unsigned int 8192) line 195 + 58 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03c05040) line 370 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03c06e60) line 93 + 12 bytes PL_HandleEvent(PLEvent * 0x03c06e60) line 522 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c86d10) line 483 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00c005c4, unsigned int 49297, unsigned int 0, long 13135120) line 951 + 9 bytes USER32! DispatchMessageWorker@8 + 135 bytes USER32! DispatchMessageA@4 + 11 bytes nsNativeViewerApp::Run() line 76 main(int 1, char * * 0x00be1870) line 137 + 11 bytes mainCRTStartup() line 338 + 17 bytes

So, the mimetype for the attachment was 'text/html', which lead to ^M being added to the end of lines on a Windows download, and a "corrupt" file for (win)zip. Anyways, reattaching as _uncompressed_ 'text/html', so one can either just test it directly over the network from Bugzilla, or save to disk as HTML. As a comparison to when I tried this last July (loading from disk, testing on the same 133MHz/24MB RAM PC): July 1999 Jan 2000 Moz ~180 sec. ~105 sec. Also, now, at the end of loading with Moz, there is no "video noise" as I noted in July. The page can also be scrolled effectively, and there is less UI lock-up while loading.

Gordon should look at this one. He owns the cache now.

Adding "crash" keyword to all known open crasher bugs.

I think we checked in a fix for this some time ago. The storage stream code would crash in low memory conditions. Please try it again.

looks like this is working on WinNT, Linux. Testing solaris soon...

Marking FIXED on: - MacOS9 2000-07-06-08-M17 Commercial - Linux6 2000-07-07-10-M17 Commercial - Win98 2000-07-07-13-M17 Commercial mss@eroch.mc.xerox.com, could you please verify? Thanks! -ckritzer