327552 - sluggish, slow mail gui response when opening mail messages for reading

Status: RESOLVED DUPLICATE of bug 599119

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Phil Wiede]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060127 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060127 SeaMonkey/1.0

Background and Problem Description:

1. Updated from latest Mozilla Suite to SeaMonkey 1.0 using the existing user profile
2. My mail folders (5 different Mail accounts using a POP3 mail server) are relatively small in size, very organized (i.e. about 20 sub folders for specific types of mail messages), and daily compressed (Compact Folders) with Trash emptied. 
3. Usually no more than 10 messages in the Inbox.
4. Reading mail messages used to be very fast (nearly instantly) in the previous Mozilla Suite. 
5. Now, with SeaMonkey it is slow - 3 seconds delay until the next message is displayed - very irritating. But switching between various mail folders is fast, as with old Mozilla.
6. Deleting the old .msf files and letting SeaMonkey rebuild them produced very little effect. The same holds true for "Empty Trash" and "Compact Folders".

I have seen some few other users reporting similar problems on different platforms (in Bugzilla and Newsgroups). It would be a relief if this could be fixed in the otherwise superb SeaMonkey suite. Kudos to the development team!

Reproducible: Always

Steps to Reproduce:
1. Open mail window
2. Open a mail message for reading
3. Wait 3 or more seconds for test display

Actual Results:  
The mail message displayed.

Expected Results:  
Display faster.

Comment 1

[Daniel B.]

I can (unofficially) confirm this.  I'm seeing similar symptoms.  

I also upgraded from Mozilla Suite to Seamonkey 1.0 
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 ) 
using an existing profile with existing messages and noticed that 
message-switching speed went from (almost) fast enough to quite sluggish--
I measured about 2.1 seconds. 

(Differences that don't seem to make a difference:  I'm running on Windows 
XP.  Many of my mail files/folders are a lot larger than 10 messages.)

When tried emptying the trash, compacting folders, deleting some (although
not all) .msf files (I think), and dragging messages from a folder to a new folder (to try to create and fill a new folder file from scratch), nothing 
made a difference.

However, at some point something I did did make a difference--at one point,
I measured a message-switching delay of 1.1 second (vs. around 2 seconds).

One thing I noticed was that switching using the "Next Unread Message" 
command (typing "n") was _faster_ than switching using up and down arrow
keys or clicking on a message's item in the message list pane.  There
was an additional 0.4 second delay.  (That seems to be a separate bad-
design-choice problem.)


Regarding switching between folders quickly, particular regarding switching 
_back_ to a folder, it seems to be because Seamonkey is caching some laid-out 
form of the message.

On Windows, when I raise some other window over part the message-view pane 
and click on a folder to switch back to, the portion of the message-view 
pane that was already exposed is very quickly updated by Seamonkey (with 
the rendering of the message I'm switching back to).  After the delay, 
Seamonkey then updates the rest of the window.

However, when Seamonkey initally updates that already exposed portion of 
the message-display pane, it seems to first draw the rendering of the 
message body and then slide it up so its top is where the message header 
pane's top usually is:  Whatever pixels were left on the screen by the 
other window in the screen region now occupied by the message body pane are 
slid up too.

That's not necessarily a problem.  However, I wonder if it suggests where
the delay might be coming from:  It seems that Seamonkey is deleting the
message header pane (or setting it to zero height) very quickly, then
doing whatever takes a while, and then restoring the header pane 
(proceeding with laying out and rendering the message somewhere in there).)

Comment 2

[Andrew Schultz]

Do you have any extensions installed?

Comment 3

[Daniel B.]

> Do you have any extensions installed?

No. 


Also, for another datapoint:  Today, mail-handling was slow again.
(About 4 seconds to delete and display.)  I compacted folders,
dragged everything in my Inbox folder to an empty folder,
compacted, and dragged all those messages back to Inbox.  Speed
returned to seemingly normal for Seamonkey (a little under a
second?).

Maybe just incidentally, something also seems to be wrong with the
wrong with either the Compact Folders command or just its 
manifestation in the UI:

When I first tried compacting folders, I got no UI feedback that
anything was happening.  After trying some second operation (I
don't recall if it was selecting Compact Folders again or doing
something else), Seamonkey got into a state where all links in
browser windows became unresponsive.  When I quit Seamonkey and
tried to restart it, the new instance noticed that the original 
instance was still running (even though all windows had gone
away), and I had to kill the original instance using the task
manager.  (Once I did that, I proceed witht the message-moving 
described in the previous paragraph.)

Comment 4

[Phil Wiede]

Neither have I any extensions installed. Updated to SeaMonkey 1.01 but I still get in average a 2 sec delay in switching between mail messages. 

Comment 5

[Phil Wiede]

Please fix this bug. It is really annoying when one has to use the mail client frequently. SeaMonkey is otherwise really good. 
Here's another observation: each additionally opened navigator window will cause an additional 1 second delay in mail message switching. 4 opened browser windows == 4 second delay in mail client navigation.

Comment 6

[Daniel B.]

> Here's another observation: each additionally opened navigator window will
> cause an additional 1 second delay in mail message switching. 4 opened 
> browser windows == 4 second delay in mail client navigation.

I can confirm that the delay varies with the number of navigator windows
open (although I don't get 1 second of delay for each window; I get about
1 second for every 10 windows).

This behavior really makes it seem that Mozilla is doing something completely
unnecessary (or extremely non-optimal) when selecting/retrieving/displaying a 
message.  








Daniel

Comment 7

[Wayne Mery (:wsmwk)]

Phil, Daniel, is the problem gone with SM 1.1.1?  http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.1.1/
If not, please try trunk http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/
and then please comment. tx

Comment 8

[Daniel B.]

> Phil, Daniel, is the problem gone with SM 1.1.1? 
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.1.1/

In Seamonkey _1.1_, it seems to be somewhat faster.  (I haven't 
done a measured timing test yet.)  

It does still slow down a bit more when more browser windows are 
open (but less than before). 

I'll upgrade to SM 1.1.1 and report back when I can.

Comment 9

[Phil Wiede]

The problem is not gone in Seamonkey 1.1.1. And a new bug seem to have been introduced with this version regarding the bookmark manager, which can become very sluggish from time to time. Basically, I click the Bookmarks menu to select a bookmark and then there might be a delay of up to 5 secs or more until the (quite large) list pops up. 

With the mail client, I experience the following through all SM versions:
- After closing and re-opening the SM suite, mail navigation is fairly responsive (opening a mail message for reading could be faster, though)
- After having SM open for some time (hours to days), using it extensively for Web browsing (always 2 windows open, sometimes 3), mail reading and bookmarking, the Mail client's UI will become sluggish again. 

Maybe this decline is caused by a memory leak? My station has 4 GB Ram. How are the mail folder's messages (Inbox & user-defined folders) parsed in this regard: once read and held in memory until mod date changes, or parsed each time the folder is accessed?

Thanks - Phil

Comment 10

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 11

[Phil Wiede]

Attachment: New SeaMonkey browser rendering bug

See my previous comment

Comment 12

[Phil Wiede]

No, I think the mail problem was resolved starting from about SeaMonkey v1.1.4 or so, as a guess. However, since about v1.1.2 (approx. a year) another rather annoying bug introduced itself in Web browsing. Every time after about 1-2 days of Web browsing, and especially after visiting eBay sites, SeaMonkey's rendering machine will go hairwire. The effect of this can be described as displaying a HTML page like the very old Web browsers of 1995/1996. In such a state, SeaMonkey will not honor anymore CSS or Javascript code, and even the HTML Table directives, as it seems. 

This display bug has been consistent since over at least one year. I tend to update SeaMonkey whenever there is a new version announced. A fix would be greatly appreciated. 

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #9)
> a new bug seem to have been

Please, file a separate bug per issue.

(In reply to comment #12)
> No, I think the mail problem was resolved starting from about SeaMonkey v1.1.4

Daniel,
Is it resolved for you too ?

> or so, as a guess. However, since about v1.1.2 (approx. a year) another rather

Please, file a separate bug per issue.

Comment 14

[Phil Wiede]

I'm sorry to report that the sluggish mail GUI response bug is back again with SeaMonkey version 1.1.10. Unfortunately, it's even more annoying (slow) then before, approx. 2.5 seconds stalling when selecting the next message. I always delete the pref files Application Registry and pluginreg.dat prior updating. And I daily empty mail trash and compact folders. The Inbox rarely contains more than 10 messages at a time. 

Comment 15

[Francesco Riva]

I can confirm this sluggish GUI response on different PCs, OS (Windows Vista Home Premium and XP SP2) and Seamonkey versions (all 1.1.x I tested so far).

Currently, I've a machine with Windows Vista HP, AMD X2 Dual Core 5000+ 2GB RAM and Seamonkey 1.1.11, *NO* resident Antivirus shield is running and:

a) in a fresh installation with only a news.mozilla.org news account created, switching from a newsgroup message to another one has a delay of 3 seconds, normal network delay included;
b) displaying a simple sent message in the Sent folder takes 3 seconds too;
c) the same actions on the same machine just few moments later last less than a second in **Thunderbird 2.0.0.16**.

I've even imported the sent message into Thunderbird in order to have exactly the same conditions, with no luck. You can image how difficult may be to use Seamonkey Mail when there is a difference of at least 2 or more seconds in displaying several thousands of messages a day.

I've tried:

1) to disable Java like suggested in the Mozillazine Forum;
2) to disable/change/uninstall my antivirus software;
3) to compact all folders, although it was a clean installation;
4) to defrag my hard disk.

Nothing worked.

Comment 16

[Francesco Riva]

I've found a solution.

It seems that every time the rendering engine is initialized in order to display an email, SM scans *all* installed plugins and produces the annoying 2+ seconds delay.

In about:plugins I've set the option plugin.scan.plid.all to "false" and now SM displays emails as fast as Thunderbird.

It's a specific SM suite bug, IMO

Comment 17

[Phil Wiede]

Great find, Francesco. However, I can't find an entry for plugin.scan.plid.all in my about:config. I'm on Mac OS X. Any ideas?

Comment 18

[Francesco Riva]

Well, I've found that option there. I've filtered for "scan" and it was among few other results.

I don't know if it's a Windows specific option.

Have you tried to add manually "plugin.scan.plid.all"?

Comment 19

[Francesco Riva]

I forgot saying I'm using SM 1.1.11

Comment 20

[Francesco Riva]

MOre info:

this option is a MS windows specific one. See:

http://kb.mozillazine.org/Plugin_scanning

However, it is surely the main cause of this issue, since I did a new, fresh installation and the delay was still there. Then I changed that option to "false" and the delay was gone.

Of course, after this change, I had to move all plugins .dll and .xpt. into the "plugins" folder under mozilla.org program folder, otherwise SM couldn't see them.

It's curious that scanning the normal plugins folder gives no delay while scanning the registry and other folders produces at least a 2 seconds delay per mail on a AMD 5000+ PC.

I suppose that there is some sort of automatic plugin scan on other platform too, but I really don't know which option should be changed in that case.

Comment 21

[toshi]

I have had same trouble within SM 1.1.x (includes 1.1.17).

I have NOT rebooted(restart) my machine every day. (use 'sleep' with windows vista)
At first or second day, it looks like slightly smooth than after days.

I've changed plugin.scan.plid.all to false today, it take about one second
to display other messages.
At one week later,I will report difference from today.

Comment 22

[toshi]

One week after, I have found one thing.

When I used navigator window, mailer responce went slower. (about 2.5-3.0 sec.)
When I opened NO html mail and NO navigator window, mailer responce didn't go slower.(about 1-1.2 sec.)

Comment 23

[Wayne Mery (:wsmwk)]

The WINDOWS issue described in comment 18 is fixed in 1.9.2 based branch in thunderbird 3.1.5 and seamonkey trunk via core Bug 599119. 

IF the original issue described still exists (and I'm not sure it does) you must test trunk (or use the workaround) so that bug 599119 doesn't impact your interpretation of response time.

FIXED or WFM?

Comment 24

[Wayne Mery (:wsmwk)]

p.s.  Bug 599119 is a big perf win affecting navigation and delete.  And I think it started in 1.9.1, not 1.8. If so, you might want to spin a new bug for the plugin issue.