Closed Bug 216374 Opened 22 years ago Closed 14 years ago

IMAP extremely slow with large pictures shown inline due to small block requests

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: kurrat, Assigned: Bienvenu)

Details

(Keywords: perf)

Attachments

(1 file)

Network traffic when opening the same mail with 5 large pics in thunderbird and OE
8.67 KB, image/gif
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 7.11 [en] Build Identifier: Mozilla Thunderbird 0.2a (20030813) Thunderbird is extremely slow displaying mails with large pictures when the "Display Attachments Inline" option is set in the view menu with IMAP messages. I use a Mercury mail server (3.32) on my local PC on which I'm also running the mail programs. As I often switch between Eudora and Outlook Express I found a local IMAP server to be the ideal solution as I have all mails available whichever mail program I use. Thunderbird principly works very well but seems to be rather slow in general (as also reported in other bugs). When I disable the "inline" option it takes roughly twice as long to open a mail message (with large attachment) than with Eudora or OE. If I enable the "inline" option it gets terrible. Connection speed cannot be the problem as I'm using only localhost. As a sample I use an email with 5 jpg's (~1.5 Meg each) * OE open this mail in ~1.5 sec and displays all pics * Thunderbird (inline off) opens the mail in ~3 sec and shows the images as attachments at the bottom. Clicking on one of the pics opens it after ~2 sec * Thunderbird (inline on) opens the mail in ~16 MINUTES displaying all pics I could live with Thunderbird taking twice the time although it's annoying but showing images inline (which I prefer) makes Thunderbird unusable for me :-( Roger Reproducible: Always Steps to Reproduce: 1. 2. 3.
I thought about how I can get more information on this problem and so I had the idea to switch on the detailed session logging of the Mercury IMAP server. I opened some big mails both with OE and Thunderbird and then compared the way they were talking to the IMAP server. What I found totally explains to me why Thunderbird is so slow. Here is an example from Outlook Express: 21:29:13.500: >> 8 UID fetch 17 (BODY[2])<cr><lf> 21:29:14.437: << * 15 FETCH (UID 17 BODY[2] {1229912}<cr><lf> Outlook request the whole body part and the server sends it in one go (in this case 1.2 MB) Now an example from Thunderbird 21:30:35.031: >> 10 UID fetch 17 (UID RFC822.SIZE BODY[]<0.12288>)<cr><lf> 21:30:36.953: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[]<0> {12288} <cr><lf> 21:30:36.031: >> 11 UID fetch 17 (UID RFC822.SIZE BODY[]<12288.12288>)<cr><lf> 21:30:37.015: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[]<12288> {12288} <cr><lf> 21:30:37.078: >> 12 UID fetch 17 (UID RFC822.SIZE BODY[]<24576.14336>)<cr><lf> 21:30:39.828: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[]<24576> {14336} <cr><lf> 21:30:39.890: >> 13 UID fetch 17 (UID RFC822.SIZE BODY[]<38912.16384>)<cr><lf> 21:30:40.828: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[]<38912> {16384} <cr><lf> 21:30:40.890: >> 14 UID fetch 17 (UID RFC822.SIZE BODY[]<55296.18432>)<cr><lf> 21:30:41.531: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[]<55296> {18432} <cr><lf> ... and so on Thunderbird request just small blocks of 12 to 18 KB each. The server sends out the first block, request finished, new request for the next block, the server must search the mailbox for the beginning of the block and send it, request finished, new request for the next block, the server must again search for the beginning of a block and send it, ...... and so on hundreds of times Would it be possible to change the fetch routine in Thunderbird so that it requests the whole mail as Outlook does? This would solve the speed problem. Roger
Summary: IMAP extremely slow with large pictures shown inline → IMAP extremely slow with large pictures shown inline due to small block requests
taking.
Assignee: scott → bienvenu
Component: Mail Window Front End → Networking: IMAP
Product: Thunderbird → MailNews
Version: unspecified → Trunk
You can turn off fetching by chunks by setting the following pref: user_pref("mail.server.serverName.fetch_by_chunks", false); where "serverName" is replaced by the name of your server in prefs.js However, there's something else going on here that seems odd. Mozilla configures the chunk size based on how fast it receives data from the server. The faster it receives data from the server, the larger the chunk size. It stores this value in prefs.js as user_pref("mail.imap.chunk_size", nnnnn); what does your prefs.js have this value as? It looks like it starts off as a small value and increases as it notices that the connection is fast. What should happen is that with a fast connection, which is what it should look like you have, the chunk_size maxes out and stays maxed out. Also, is this the only imap server you connect to?
I looked for these settings and found them in the file thunderbird\defaults\pref\mailnews.js Here are some lines from this file: pref("mail.imap.max_cached_connections", 10); pref("mail.imap.fetch_by_chunks", true); pref("mail.imap.chunk_size", 10240); pref("mail.imap.min_chunk_size_threshold", 15360); pref("mail.imap.max_chunk_size", 40960); pref("mail.imap.chunk_fast", 2); pref("mail.imap.chunk_ideal", 4); pref("mail.imap.chunk_add", 2048); I tried to set the fetch by chunks to false as you suggested and it gave me a great speed boost. For the mail mentioned at the beginning (with inline on) I got down to hand stopped 41 sec. Still far away from the < 2 sec OE requires but much better than the ~16 min I had before. Actually, I can see the images (jpeg) build up in the editor window ower this time span. Again the test with inline off. It takes a few seconds to display the mail with the attachment list at the bottom. If I double click one of the pics a little progress window pops up and among other settings shows the connection speed which is at ~700 kb/sec If Thunderbird would maintain this speed with inline on then the pics should display in less than 9 sec (not the 41 it actually takes). As OE is capable of downloading the message in less than 2 sec this means that the Mercury server is capable of sending the data out with > 3000 kb/sec. I get this speed also with MS Outlook, Eudora and Opera (M2 mail client) And yes, its the only imap server I use.
I rather suspect there's some interaction between the mail server and mozilla running on the same machine that's not working well. I can load large messages from an imap server running on a different machine in my home network much faster than you can load a message from an imap server on the same machine. With fetching by chunks turned on, I can load a 5MB message in < 10 seconds, with a debug build.
I don't think that there are interactions with the local machine. However I got my notebook from the office (500MHz PIII) and installed the server there and copied the mail folders. This surely rules out any localhost problem. Unfortunately I only have a 10 MBit hub in my local network but as I use it 99.9% of the time to connect my computer to my DSL modem it made no sense so far to get a 100MBit switch. I changed the IMAP server entry in both Thunderbird and OE and tried to open the same mail with the 5 pics as before. OE was much slower now. It took about 9 to 10 sec to open the mail. This must be because of my 10Mbit hub where I don't get the > 3MB/sec transfer rates that I calculated when using localhost. Thunderbird was also a bit slower than before ( inline on and fetch by chunks off). The interesting part is the amound of data transferred. I took some snapshots from my firewall software showing the incomming traffic. Both have the same resolution in X and Y, so they are comparable. When I look at the graph for OE I see one transfer. The graph for Thunderbird shows 6 transfers (probably one for the mail body and one for each of the 5 pics). The amound of data transferred should be proportional to the area below the curve. Surprisingly each of the Thunderbird transfers seems to have the same size than the OE transfer. Somehow this looks like Thunderbird is transferring the mail 6 times...... ??????
It doesn't sound like interactions with the localhost, you're right. It does sound like your imap server is very slow with handling partial message fetches, which is unfortunate - in theory, doing a partial message fetch would just involve a single seek or two. Mozilla might be fetching the message multiple times but it shouldn't be. You should be able to tell from an imap protocol log. Here are the instructions for generating a log: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap It will be a huge log, however. You can look at the fetches and see if we're fetching the message more than once. What should happen is that we fetch the body structure for the message, and notice that all the parts are going to be rendered inline, so we fallback to fetching the whole message.
Is there any reason why that chunked transfer would ever be needed? I would think the slicing up of data in managable chunks for transmission over the network is the responsibility of the TCP layer. There is a TCP window size that defines how much data the server can send to the client, and a sliding window algorithm that sends back ACKs as fast as the client can digest the information. Another end-to-end chunking mechanism seems to be overkill, and apparently can cause slowdowns. When there is no good reason for it, I vote for it being removed from the code and all transfers to be done in one go (as Outlook apparently does too) Regarding the fetching of the same message several times, I have seen similar things happen as well. Will see if there is a reproducible scenario. What I sometimes saw was that a message with a single (huge) .jpg attachment was displayed, including the photo, and then immediately the photo was transferred again. One would see it build up on the screen 2 times.
the reason we fetch by chunks is so that the user can switch to a different message while the first message is getting loaded - with the chunk approach, we just wait for the current chunk to finish, and then start loading the new message. W/o chunking, we'd have to kill the connection, and build up a new connection, which can involve a lot of network traffic and server load. IMAP doesn't have a way of gracefully stopping a message fetch other than what we're doing. Your IMAP server seems to be pathalogical in its handling of partial fetches; it's the only server I've heard of that performs so poorly in that respect, but we have a pref that you can use to turn it off. What I'm really concerned about is the refetching of images - any help you can give in finding a reproducible case for that would be much appreciated.
I am running Moz 1.5b on Win98, connecting on a LAN to a Courier IMAP server, and I set up the logging as described in comment #7. I openend a message that had 3 inline JPG attachments and checked the log. The message was only fetched once, in chunks that increased in size up to the maximum. I then did a "Save All" on the attachments. To save the 3 attachments, the log file showed that the entire message (all attachments included) was downloaded 3 times total. This would seem to be a case of re-fetching to me. No wonder "Save All" seems to take so long. I tried with a different message with 3 different JPG attachments and got the same result.
Today I got some time for testing again and so I switched on the session logging and checked what Thunderbird is doing. Show Images inline is ON and partial fetch is OFF. The mail contains 5 big jpeg images and has a total size of 6 MB. Here is an extract from the log file: 20:54:11.812: >> 5 UID fetch 17 (BODYSTRUCTURE)<cr><lf> 20:54:12.812: << * 15 FETCH (UID 17 BODYSTRUCTURE ((("text" [...snip...] 20:54:12.828: << )<cr><lf> 20:54:12.828: << 5 OK UID FETCH complete.<cr><lf> 20:54:12.843: >> 6 UID fetch 17 (UID RFC822.SIZE BODY[])<cr><lf> 20:54:15.484: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[] {6090340}<cr><lf> [...] 20:54:35.515: << 6 OK UID FETCH complete.<cr><lf> 20:54:35.656: >> 7 UID fetch 17 (UID RFC822.SIZE BODY[])<cr><lf> 20:54:38.734: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[] {6090340}<cr><lf> [...] 20:54:59.781: << 7 OK UID FETCH complete.<cr><lf> 20:54:59.843: >> 8 UID fetch 17 (UID RFC822.SIZE BODY[])<cr><lf> 20:55:01.828: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[] {6090340}<cr><lf> [...] 20:55:23.859: << 8 OK UID FETCH complete.<cr><lf> 20:55:23.921: >> 9 UID fetch 17 (UID RFC822.SIZE BODY[])<cr><lf> 20:55:26.421: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[] {6090340}<cr><lf> [...] 20:55:49.953: << 9 OK UID FETCH complete.<cr><lf> 20:55:49.015: >> 10 UID fetch 17 (UID RFC822.SIZE BODY[])<cr><lf> 20:55:51.171: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[] {6090340}<cr><lf> [...] 20:56:12.765: << 10 OK UID FETCH complete.<cr><lf> 20:56:12.812: >> 11 UID fetch 17 (UID RFC822.SIZE BODY[])<cr><lf> 20:56:14.468: << * 15 FETCH (UID 17 RFC822.SIZE 6090340 BODY[] {6090340}<cr><lf> [...] 20:56:36.609: << 11 OK UID FETCH complete.<cr><lf> As can be seen, Thunderbird requests first the body structure, then it requests the whole mail. At this time TB shows the mail text as well as placeholders for the images. As the whole mail is allready downloaded it should be possible to show the images not only the placeholders. Next TB downloads the whole mail again and extracts the data for the first picture from it (only this is shown on the screen). Then TB downloads the whole message again and extracts the data for the second image and so on. The whole mail is downloaded 6 times although one time would have been enough.
>the reason we fetch by chunks is so that the user can switch to a different message while the first message is getting loaded - with the chunk approach, we just wait for the current chunk to finish, and then start loading the new message. Ok that sounds like a valid reason. At least, for the case of dialup modem access to an IMAP server. On a LAN, and with IMAP performance as it should be, the user probably cannot interrupt the transfer in time, or the program could just throw away the remainder of the message (it should be able to transfer 8MB/sec over a 100Mbit LAN, but it is nowhere close to that...). >Your IMAP server seems to be pathalogical in its handling of partial fetches Well, in my case (UW IMAP) it does not seem so bad, but the overall performance of IMAP in Mozilla is still very poor. It seems like a combination of many issues now. Unfortunately I am usually reading bugzilla at home and I need to do these tests on the fast systems and LAN at work. Hope to get around to the photo attachment test soon.
>Ok that sounds like a valid reason. At least, for the case of dialup modem >access to an IMAP server. It's also valid for "high speed" connections like DSL or cable modem, which is a large and growing percentage of our users. I just checked in a fix for bug 218874 which should speed up imap operations on a high speed LAN significantly - in one test I did, the time to download a multi-MB message was cut in half. This was on a debug build but I've heard that release builds are much faster now too. This fix will appear in tomorrow's (9/14) build. I has nothing to do with downloading messages multiple times, however.
In my eyes the fetching by chunks is not a problem as long as it can be swichtched off if neccessary. This would mean having a checkbox somewhere in the options dialog. However I think the even better solution would be a smart handling of the chunk size which automatically adjusts to the network speed. When looking at the prefs it currently starts with ~10KB and slowly increases to a maximum size of ~40K. These values might be fine for dial up and slow DSL connections but not for a 100MBit LAN (or do you really need to give the user a chance to switch to another message every ~1.2 milliseconds?). Having said that I had the following idea. Whenever a transfer to the IMAP server is done, the speed could be tracked in a new "global variable" e.g. ServerSpeed. This starts allready when retrieving the list of folders and the list of messages in a mailbox. Each transfer could somehow update the speed (e.g. 80% old value + 20% new speed) and in such Thunderbird or Mozilla Mail would always know the current estimated speed. Comming back to the 10KB it currently starts with, this means ~2 seconds on a dial up modem. So we could take the ServerSpeed times 2 and get an optimized chunk size depending on the current connection speed. For LAN connections this chunk size will be so big that there will be only very few mails transferred in chunks. Just think about this. This obviously does not solve the multiple mail download. Regarding this I made another test which created a strange result in my eyes. In order to speed up things, I selected the folder for offline usage. My assumption was that now, once downloaded the mail will display faster. However the mail was still downloaded 6 times. Switching to another message and comming back to this mail downloaded it again 6 times. Thunderbird was not willing to save the downloaded mail to disk for offline usage and downloaded it over and over again. Only by selecting "properties" on the folder and clicking the "download now" button placed it on the disk and from then on the mail display was as fast as expected.
Roger, as I said earlier: "However, there's something else going on here that seems odd. Mozilla configures the chunk size based on how fast it receives data from the server. The faster it receives data from the server, the larger the chunk size". I also recently removed the upper bound on the chunk size; that's checked into 1.6. The one thing that's missing is that we don't remember this setting across mozilla sessions, but, there's no guarantee that you're on the same network connection across sessions. Re storing the message for offline use, there's a pref that limits the automatic downloading of messages for offline use based on the message size, which might be coming into play. The other more likely possibility is that the message you're looking at is not getting fetched completely because not all the parts are inline. In that case, we only fetch the inline parts, and can't store the message for offline use, because we haven't downloaded the message. If you send me the message in question, I can look at it.
Hi David have you not received it? I will send it again. Roger
I found it to be very slow under Linux also. This is a fast client and a fast server. details: http://mailman.fastxs.net/pipermail/dbmail/2003-November/003814.html Changing pref("mail.imap.chunk_size", 10240); pref("mail.imap.max_chunk_size", 40960); to pref("mail.imap.chunk_size", 10240000); pref("mail.imap.max_chunk_size", 40960000); resolved the problem for me.
Product: MailNews → Core
Keywords: perf
QA Contact: asa → networking.imap
Hi David, please take another look at this issue. It is still present in current releases and it is very annoying. It might be a valid reason for a corporate customer to revert from TB as a mail client back something else. If found this behavior in current releases: TB v1.5.0.14 (Debian) and in TB 2.0.0.14 (WinXP SP3). Assume you have a MIME multipart/mixed message with mime/alternative in body part 1 (1.1 = text/plain, 1.2 text/html) and 9 image/jpeg attachments in parts 2 through 10. When Thunderbird (v1.5 and 2.0 alike) is accessing the message with attachments viewed inline, the total data size fetched from the IMAPv4 server is around 9 times the total message size. Before a 18 MB message (with 9 pictures attached) is displayed, 166 MB of data need to be transferred. Server is a current Courier-imap (with and without enhanced IDLE mode) Junk evaluation is turned off. Setting mail.imap.fetch_by_chunks or mail.server.default.fetch_by_chunks to false makes no difference. Setting mail.imap.mime_parts_on_demand or mail.server.default.mime_parts_on_demand to false makes no difference. Apparently, Thunderbird still has an issue with multipart messages, where attachments are not properly isolated from the message when being displayed inline. -------------------------------------------------- Analysis in detail (wireshark) Message size (= file size in Maildir folder): 18 MB Upon opening the message - Request BODYSTRUCTURE -- server answers with correct message characterisation: (text, plain, 1.302 Byte) (text, html, 5.140 Byte) (image, jpeg, 2.236.036 Byte) (image, jpeg, 2.352.150 Byte) (image, jpeg, 2.402.936 Byte) ..(9 attachments) Then, the message is fetched part by part. Large parts are transferred by chunks Request BODY[HEADER] * 126 FETCH (UID 8207 BODY[HEADER] {2016} BODY[1.MIME] BODY[1.1.MIME] * 126 FETCH (UID 8207 BODY[1.1] {1302} BODY[1.2.MIME] * 126 FETCH (UID 8207 BODY[1.2] {5140} BODY[2.MIME] * 126 FETCH (UID 8207 BODY[2]<0> {10240} * 126 FETCH (UID 8207 BODY[2]<10240> {10240} * 126 FETCH (UID 8207 BODY[2]<20480> {10240} * 126 FETCH (UID 8207 BODY[2]<30720> {10240} * 126 FETCH (UID 8207 BODY[2]<40960> {10240} * 126 FETCH (UID 8207 BODY[2]<51200> {10240} * 126 FETCH (UID 8207 BODY[2]<61440> {10240} * 126 FETCH (UID 8207 BODY[2]<71680> {10240} .. * 126 FETCH (UID 8207 BODY[2]<2222080> {10240} * 126 FETCH (UID 8207 BODY[2]<2232320> {3716} (..) BODY[10.MIME] * 126 FETCH (UID 8207 BODY[9]<0> {10240} (..) * 126 FETCH (UID 8207 BODY[2]<2283520> {6992} After a complete transfer, Thunderbird fetches the message again, starting with part BODY[1.1] * 126 FETCH (UID 8207 BODY[1.1] {1302} After 9 full transmissions, the transfer is completed. Request 16370 noop 16370 OK NOOP completed Request DONE 16373 OK IDLE completed The IMAP server log shows the huge amount of transferred data: Jul 14 13:45:34 as00s001 imapd: Connection, ip=[::ffff:10.1.1.2] Jul 14 13:45:34 as00s001 imapd: LOGIN, user=myname, ip=[::ffff:10.1.1.2], protocol=IMAP Jul 14 13:45:34 as00s001 imapd: LOGOUT, user=myname, ip=[::ffff:10.1.1.2], headers=0, body=0, rcvd=134, sent=579, time=0 Jul 14 13:45:34 as00s001 imapd: LOGOUT, user=myname, ip=[::ffff:10.1.1.2], headers=1436, body=164650331, rcvd=749641, sent=168181141, time=281
I am also experiencing performance problems. Mine started with TB2. Hopefully this can give more clues to this problem. I use Outlook and Thunderbird. Given the same mailbox file (on the IMAP server), Outlook is always faster than Thunderbird at opening any message. This morning, I received an email with an 8980KB wmv attachment. When I clicked on this file, it took over 90 seconds to load. (I know it was longer, but didn't look at the wall clock in the first few seconds.) I dragged this large message from the server (inbox) to a local folder (Humor). The inbox now has 81 message and 7MB. The Humor folder now has 122 messages and is 83MB. The large message is the last message in the Humor folder. Now I try to open the large file in the Humor folder. The fetch_by_chunks setting has no effect. (I didn't expect any.) * With mail.imap.fetch_by_chunks = false, it took ~100 seconds to open. * With mail.imap.fetch_by_chunks = true, it took ~100 seconds to open. During this time, I had three Thunderbird windows open: Inbox (on IMAP server), Humor (local folder) and config editor. No Thunderbird window are updated for ~100 seconds; they are updated when the large message in Humor is finally opened. I was looking at my hard drive and it was not busy. (The blinky light is hardly visible.) Then, I closed all windows, except Humor. I clicked on the second to last message in Humor (it displays immediately). I clicked on the large message and it took ~100 seconds to load. Disk not busy. Task manager shows that the CPU is using 95% of my CPU. This performance problem is NOT limited to interaction with a server.
Product: Core → MailNews Core
A lot of things have been changed in the way imap is being handled in thunderbird 3.0b2 (http://www.mozillamessaging.com/en-US/thunderbird/early_releases/) can anybody experiencing the issue give a try with TB3.0b2 and post feedback here afterwards ?
I don't know if anyone is still looking at this issue, but I have tried 3.0b2 and it appears to be much faster at retrieving these kinds of messages. However, since that's still beta, it'd be nice if there was a fix for the performance issues with the stable version.
Rougu , others, have you tried version 3 final release, with imapautosync both on and off Reporter Roger is gone (unless Rougu is Roger) - email addres bounces.
WFM per comment 21. (everyone else seems to be gone)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
I hate to say it but this bug is still valid in 2014, eleven years after it was reported. Luckily the mail.server.serverName.fetch_by_chunks option has fixed the problem for me. Before disabling it Thunderbird 31.1.2 downloaded messages with many JPEG attachments at 100KB/sec, after disabling it it downloads the same messages at 5MB/sec, i.e. 50 (fifty) times faster. I can only say WTF and why the hell this bug report is marked fixed. It's not fixed even though the application is capable of doing things properly - it's just its default utterly broken settings that kill its performance. P.S. My IMAP provider works via SSL exclusively.
(In reply to Artem S. Tashkinov from comment #24) > > I can only say WTF and why the hell this bug report is marked fixed. It's > not fixed even though the application is capable of doing things properly - > it's just its default utterly broken settings that kill its performance. unless you reproduced this 4 years ago then you misinterpret the most recent information in the bug report: - the people who tested AT THE TIME OF CLOSING did not reproduce the issue, so it was closed worksforme - WORKSFORME does not necessarily mean fixed, as in "it can't be happening to anyone now or in the future" No one has complained in the 3/4 years since the bug was closed (so we won't be repopening this) suggests you may be seeing a new bug, or have a local issue. Please file a support report https://support.mozilla.org/en-US/questions/new/thunderbird or a new bug.
I've been having this problem forever, but never took the time to search for it before, I just look at the file with webmail or my phone mail app. Having big image files inline on a message seems to be the problem. I see them cut. By increasing the chunk size I can see the images gets bigger, but still cut. I added a big number (40960000) and the messages stop loading. So instead I just disabled fetch_by_chunks and it's now working. I'm not sure if there are any negative input of having chunks disabled. Here's a same image (an animated gif) that I added inline with Thunderbird itself: http://imgur.com/FWugmAT Regards, Jose
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: