Max Alekseyev Reporter
	Description • 21 years ago

OS/2 build 20030627

To reproduce:
1. Get large text e-mail message (in my case it was 3Mb of uuencoding that is
unrecognized as an attachment)
2. Click on the message title in MailNews window, so it will be being loaded
3. It's a known bug (?) that loading of large text message takes very LONG time
(in my case it's about 10 minutes)
4. Don't wait until message is completely loaded, but try to save it via
File->Save As->File
5. Mozilla opens file selector dialog and hangs

	Mike Kaply [:mkaply]
	Comment 1 • 21 years ago

1.4 build or GCC build?

	Max Alekseyev Reporter
	Comment 2 • 21 years ago

1.4 VAC build

	Mike Kaply [:mkaply]
	Comment 3 • 21 years ago

I'm not seeing this. Can you forward the message to testing@kaply.com?

Thanks

	Max Alekseyev Reporter
	Comment 4 • 21 years ago

Michael, I don't have original message. But I think it's easy to prepare fresh
new testcase. But...
while preparing a testcase for you I've faced another related bug 212358 that
should be much easier to reproduce.
Anyway I hope to send you testcase for current bug soon.

	Max Alekseyev Reporter
	Comment 5 • 21 years ago

Michael, I've just sent a testcase message to testing@kaply.com

	Mike Kaply [:mkaply]
	Comment 6 • 21 years ago

Well this one won't be fun to debug.

Definitely OS/2 only.

	Martin Sch
	Comment 7 • 21 years ago

Sounds like a focus problem...

	OstGote!
	Comment 8 • 21 years ago

(In reply to comment #0)
> 4. Don't wait until message is completely loaded, but try to save it via
> File->Save As->File
> 5. Mozilla opens file selector dialog and hangs

Hmm ... this is a modal dialog, right? Could this be a dupe of Bug 74331
?

	Max Alekseyev Reporter
	Comment 9 • 21 years ago

No, this dialog is not modal.

	Max Alekseyev Reporter
	Comment 10 • 21 years ago

This bug seems to be more general. It's not related a particular saving
procedure but to *any* action during the loading process. Any action like
switching to navigator window while the message loading process is going on
leads to a hangs.
See bug 210946 comment 6 for details.

	Troodon
	Comment 11 • 20 years ago

I cand reproduce this bug in Win32, please see bug 238440 . I thik bug 151097 ,
bug 152842 , bug 21583 , bug 238440 , this one and of course bug 210946 are
dupes or at least they are somehow related. Maybe we need a meta bug for
tracking this kind of bugs?

	Troodon
	Comment 12 • 20 years ago

It is bug 215183 and not bug 21583, sorry.

	Wayne Mery (:wsmwk)
	Comment 13 • 18 years ago

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

	Wayne Mery (:wsmwk)
	Comment 14 • 18 years ago

(In reply to comment #10)
> This bug seems to be more general. It's not related a particular saving
> procedure but to *any* action during the loading process. Any action like
> switching to navigator window while the message loading process is going on
> leads to a hangs.
> See bug 210946 comment 6 for details.

Felix, can you recreate this issue per bug 210946 comment 6?

Kaply only said in comment 6 "definitely only OS/2", which leaves me wondering was this behavior on OS/2 ever independently confirmed?  I did not find any OS/2 only bugs searching on perf or hang.  And no response from reporter. 

WFM 4meg text file, but I'm not OS/2.

	Felix Miata
	Comment 15 • 18 years ago

I've never seen a 3-4M plain text message. All messages with binary attachments of any kind whatsoever goto my trash automatically. For me to test, someone will have to put some mbx file that contains one in a zip on ftp somewhere, or attach it here if it can zip down to under 300k.

	Andy Willis (abwillis)
	Comment 16 • 18 years ago

Here is a 3,619,559 file zipped to 40,173. 
I opened the file in EPM.exe and dragged the contents to a new compose window (I have every setting set to plain text and have no html settings turned on).  It took about 2 minutes to copy the text in.  I then saved it as a draft.  Opening the draft took about 10 minutes at 99% cpu usage in preview.  The UI was not locked during this time.  I then opened the draft into a new window and it went 99% cpu and this time the UI (all of Seamonkey) was locked (others apps did still respond... slowly due to cpu usage).  This took 2 minutes.

	Andy Willis (abwillis)
	Comment 17 • 18 years ago

Just thought to double check something else...
I opened the file in epm and then opened a second instance of epm and dragged the contents to it and it happened almost instananeously so it is Mozilla code and not OS/2 or epm that caused the high cpu usage copying the data over.  I also tested moving the data from e.exe to epm.exe (e.exe would not let me drag the text to it) and again it was immediate (tested to make sure that epm didn't just move it over somehow internally bypassing something on the system).  
Also I realized that I did not state in my last post that while copying from epm.exe to seamonkey compose window went to 99% cpu during those 2 minutes but did not lock up the browser window during that time. 

	Felix Miata
	Comment 18 • 18 years ago

I used wget to save attachment 230841 [details] to disk, extracted the content with FC/2, prepended some message headers with FC/2, copied the result to my maildir with FC/2, opened yesterday's SM 1.1b nightly, and opened the message. I used my stopwatch expecting it to take some time. It took 12 seconds, pegging the CPU as you can see, but not for particularly long considering the size of the message. The whole activity meter width here represents roughly 1.5-2 minutes time.

	Wayne Mery (:wsmwk)
	Comment 19 • 17 years ago

My guess is the bug can be closed for the original problem report comment 0 but need to wait for OS/2 trunk - Felix says OS/2 trunk is busted right know due to cairo.  Not sure about comment 10.

12 seconds is better than SM windows than SM windows trunk :)  Windows trunk SM on my machine is 18 seconds, 10 seconds of that includes network download (overlaps with displaying the message).  The message display these days is nontrivial due to phishing processing, otherwise it would probably be done displaying when network loading finished.

	Jesse Ruderman
	Comment 20 • 17 years ago

Unless there's something going on here that's specific to OS/2 or mail, this is a dup of bug 367116, "Hang loading 20MB text/plain page".

	Wayne Mery (:wsmwk)
	Comment 21 • 17 years ago

(In reply to comment #16)
> Created an attachment (id=230841) [details]
> 3,619,559 text file
> 
> Here is a 3,619,559 file zipped to 40,173. 
> I opened the file in EPM.exe and dragged the contents to a new compose window
> (I have every setting set to plain text and have no html settings turned on). 
> It took about 2 minutes to copy the text in.  I then saved it as a draft. 
> Opening the draft took about 10 minutes at 99% cpu usage in preview.  The UI
> was not locked during this time.  I then opened the draft into a new window and
> it went 99% cpu and this time the UI (all of Seamonkey) was locked (others apps
> did still respond... slowly due to cpu usage).  This took 2 minutes.

bug 390051 also has such a large file. 

In (slow?) environments perhaps _networking_ is the biggest performance issue.  But in my case with gigabit speed I find networking to be second to rendering - indeed it is nasty that the testcase file from bug 390051 took twice as long for Thunderbird than to display as FF.  

Vista:
* Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007110805 Minefield/3.0b2pre
* TB version 3.0a1pre (2007120503)

TB took 2x longer, 3 minutes from local disk with file, open saved message, but FF took 1.5 minutes


Windows:
1. Machine A(XP) about 30 seconds to display message, about 40 to open draft in edit as new message
2. Machine B(Vista) - (faster machine) 15 seconds display and 15 seconds edit
   (TB subsequently hung for 2 minutes on this vista machine, with high cpu (not high memory usage). Then FF did same for about 30 sec.  very Odd...)
3. load message from local disk as eml file, 5 sec (5 sec also for FF as html file)


Jesse in comment #20
> Unless there's something going on here that's specific to OS/2 or mail, this 
> is a dup of bug 367116, "Hang loading 20MB text/plain page".

indeed surely not os/2 only.  but bz cautions against duping perf issues without a profiled testcase like in bug 367116. This bug doesn't have a testcase from reporter.  Not sure where that leaves us except to create a testcase?

FWIW, bug 380897 is another slow render email issue, but might not progress beyond invalid.

	Wayne Mery (:wsmwk)
	Comment 22 • 16 years ago

qawanted to find a clear core bug to set as blocker, whether it's bug 367116 or something else.

message display bugs (non mime-related) going to message reader UI

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)
	Comment 23 • 15 years ago

Related to bug 440641?

Getting this on my QA plate to see if I can get a hang stack to know exactly where it's hanging (or spending a lot of time on).

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)
	Comment 24 • 15 years ago

(In reply to comment #0)
> To reproduce:
> 1. Get large text e-mail message (in my case it was 3Mb of uuencoding that is
> unrecognized as an attachment)
> 2. Click on the message title in MailNews window, so it will be being loaded

With Thunderbird 3 Beta 2 on the Mac, if a large email is coming in, it won't even show in the message title in Mail 3-pane, so step 2 is invalid.

	Peter Weilbacher
	Comment 25 • 15 years ago

What does it do instead of showing the eMail in the list of eMail in INBOX? But you missed the relevant point (which is not step 2), while displaying the message body it is slow and consumes lots of CPU.

In any case, SeaMonkey still does display incoming eMails in the list of mails in that INBOX, so let's move this back to MailNews Core. We can also move it back to OS/2, if you guys can't reproduce it any more on other platforms (although see comment 21).

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)
	Comment 26 • 15 years ago

(In reply to comment #25)
> What does it do instead of showing the eMail in the list of eMail in INBOX? But
> you missed the relevant point (which is not step 2), while displaying the
> message body it is slow and consumes lots of CPU.

Well, the progress bar is moving at the bottom, and when it completes, the message then displays in the list. It was slow downloading the email but that's probably because of my slow net connection. There wasn't a significant UI slowdown consuming excessive CPU, during which I could click on other inboxes, view other messages, and such, but that's probably because I'm on a C2D MBP.

	Peter Weilbacher
	Comment 27 • 15 years ago

OK, to reproduce again (using Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b4pre) Gecko/20090422 SeaMonkey/2.0b1pre which is the latest OS/2 SM nightly available), I did the following:

- edit the Sent file representing the Sent folder in Local Folders to
  add a long plain text message (I used the source code of the SQLite
  amalgamation and all README files of the OS/2 nightlies since last
  summer)
- rebuild the summary file from the properties dialog
- the eMail listing now shows a new message of size 3917KB (I hope that
  is large enough)
- double click on the message, it opens in a new window (I am running
  in 2-pane mode)
- it takes 30 to 35s to finish displaying the message and it is SM reacts
  slowly during this time if at all

FWIW, loading the mailbox file (which contains five more, but very small messages) in the SM browser window takes about 16s to complete.

Hardware: Core2Quad P9650, one core displays 100% CPU while message is loading.


Finally, I did the same in a fresh installation (and fresh profile) with Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b4pre) Gecko/20090422 Shredder/3.0b3pre:

- in standard 3-pane mode, the message loads in about 20s and TB does
  react albeit slowly
- in 2-pane mode, it takes 30 to 50s and at times TB may lock up

So, I guess the problem is still there in both apps.

	Peter Weilbacher
	Comment 28 • 15 years ago

This is the mailbox file that I have tested with (I removed the extra small messages). It is still slow, but during the last few tests (both with mail opening in seperate window and with 3-pane view) SM stayed responsive.

	Peter Weilbacher
	Comment 29 • 15 years ago

With this mailbox file I now tested on a /slower/ laptop (Core2Duo P8600) and Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4pre) Gecko/20090420 SeaMonkey/2.0b1pre (my own 64bit build).

It loads in 2 or 3-pane view in 10-15s and in the SM brower window in 5s and SM stayed fully responsivce. So, I think this tells me that this has gone back to being an OS/2-only problem. But it would be great, if somebody else could verify that on another system.

	Wayne Mery (:wsmwk)
	Comment 30 • 14 years ago

John (or anyone), can you test this using current trunk and describe current performance?  And if possible also bug 319143 and bug 367116.

	rsx11m
	Comment 31 • 12 years ago

Per (broken) testcase in bug 831226, this issue still applies.