User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:18.104.22.168) Gecko/20060127 SeaMonkey/1.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:22.214.171.124) 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.
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:126.96.36.199) 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).)
Do you have any extensions installed?
Version: unspecified → 1.8 Branch
> 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.)
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.
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.
> 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
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
> 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.
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
Version: 1.8 Branch → SeaMonkey 1.1 Branch
Can you reproduce with SeaMonkey v1.1.9 ?
See my previous comment
(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.
OS: Mac OS X → All
Hardware: Macintosh → All
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.
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 188.8.131.52**. 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.
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
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?
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"?
I forgot saying I'm using SM 1.1.11
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.
Assignee: mail → nobody
QA Contact: message-display
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.
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.)
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?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 599119
You need to log in before you can comment on or make changes to this bug.