Closed Bug 1382008 Opened 7 years ago Closed 7 years ago

Increase maximum size of a cache entry from 15 MB to 25 MB

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Version:
52 Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr5255+ fixed, thunderbird56 fixed, thunderbird57 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 57.0
Tracking Flags:
Tracking Status
thunderbird_esr52 55+ fixed
thunderbird56 --- fixed
thunderbird57 --- fixed

People

(Reporter: omgitsraven, Assigned: jorgk-bmo)

Details

Attachments

(1 file)

1382008-cache-size.patch
1.29 KB, patch
rkent
: review+
jorgk-bmo
: approval-comm-beta+
jorgk-bmo
: approval-comm-esr52+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

1) Receive an email with more than (approximately) 10 MB of images in it (either inline or as attachments, as long as the attachments are then PLACED inline by Thunderbird upon viewing the email, which seems to be the standard behaviour).
2) Hit 'reply'.


Actual results:

The 'write' window appears, containing the expected 'from' address and subject line, but LACKING any 'to' address, and the body of the message is empty.


Expected results:

The new message should be addressed to the person(s) being replied to, and should have the message being replied to quoted in its body.
OK, I just discovered something -- if I leave the 'write' window open and untouched for about a minute, eventually the 'to' field and the quoted message will suddenly appear where they should be. But to be clear, there's no progress meter, no spinning cursor, nothing preventing me from interacting with the window during this length of time. If I fill the fields in manually and send the email before that minute is up, there's no indication that it was in the middle of something.
Hmm, I've just replied to a message with a 20 MB attachment and the reaction was instant.

Replying to a message with a 5 MB embedded image took few seconds.

When you say reply, where is the original stored? In a local folder or an IMAP folder? And if IMAP, is the folder synchronised for offline use?
Summary: Replying to an email with large embedded images causes an empty "to" field → Replying to an email with large embedded images causes filling of "To" field and body to be delayed by up to a minute
To be clear, was the 20 MB attachment an image? This only happens when images show up inside the message window.

I'm doing this all with a Gmail account that I check in Thunderbird, and if I hit save, the draft shows up on the Gmail website. (I think that means IMAP, right? It's been a while since I set it up.)

When I right-click the 'drafts' folder and do 'properties' > 'synchronization', "select this folder for offline use" isn't checked.
No, the 20 MB attachment wasn't an image, sorry, I misunderstood your "either inline or as attachments" by not fully reading the "as long as the attachments are then *PLACED inline*", mind you it was past 2 AM :-(

Yes, Gmail is connected via IMAP. Surely the reply is slow since the image must be loaded. If the folder isn't selected for offline use, then this can cause additional delays. I'm a bit surprised, since the image should be cached locally from previously viewing the message. Either the cache is slow or it's a caching bug, I'd have to test this. Setting NI so I don't forget.
Flags: needinfo?(jorgk)
Flags: needinfo?(jorgk)
Summary: Replying to an email with large embedded images causes filling of "To" field and body to be delayed by up to a minute → Replying to an email with large embedded images causes filling of "To" field and body to be delayed by up to a minute if IMAP folder is not selected for offline use
OK, here we go, I created a message with a 5 MB embedded image in an IMAP folder not synchronised for offline use.

Displaying the message gives this status message: "Downloading message..." and debug shows that the message is downloaded.

Going to a different message and returning to the message with the embedded image shows "Loading message..." and debug shows that the message is retrieved from the local cache which is always used for non-synchronised folders. This takes about 12 seconds.

Replying to the message takes 14 seconds, the To field is filled in pretty much instantaneously and the image appears in the body after 14 seconds. Debugging shows that the image is retrieved from the local cache as it should be.

I'm doing this testing on a "middle of the road" machine, AMD A10-7860K APU, 8 GB RAM and an SSD.

So, reporter, how long does it take to actually view the message before replying? Or do you not view it before replying, in which case it would really be fetched from the server when you hit reply.

Altogether, I don't think I can fix anything here.
To reiterate -- the bug doesn't happen for me until the images are OVER 10 MB (total). Under 10 MB it's instant; this isn't something that gets gradually worse, it either happens or works perfectly. (Also I'm not sure if it's EXACTLY 10 MB on every machine, so maybe go up to 20 MB of images or more just to make sure.)

Selecting the incoming message says "downloading message..." and takes nearly a minute before the text of the message appears, and more than 3 minutes until all of the images are loaded. Once it's loaded, clicking to another message in the same inbox and then back to the big message takes exactly as long as it did the first time, it appears to not be caching whatsoever.

I'm not hitting reply until after it's fully loaded.

Also -- even after the 1 minute delay that fills in the 'to' address in the reply, the images still don't appear quoted in the reply body, only the text does. (I wasn't aware the images were meant to appear in the reply.)

I can send you an email that triggers the bug for me, if that would help.
(In reply to omgitsraven from comment #6)
> Selecting the incoming message says "downloading message..." and takes
> nearly a minute before the text of the message appears, and more than 3
> minutes until all of the images are loaded. Once it's loaded, clicking to
> another message in the same inbox and then back to the big message takes
> exactly as long as it did the first time, it appears to not be caching
> whatsoever.
Just out of interest, when you click onto the big message a second time, do you see "Downloading message..." (message fetched from server) or "Loading message..." (message loaded from offline folder or cache)?

In any case, from what you describe, you've hit the cache limit which is currently set to 15 MB. To increase it, do this:
Tools > Options, Advanced, General, Config editor. Paste browser.cache.memory.max_entry_size into the search. Change value from 15000 to - say - 30000 (30 MB). Next paste browser.cache.memory.capacity into the search. Change value from 120000 to 240000. It needs to be eight times the other value.

You should consider selecting the folder for offline use as well.

> (I wasn't aware the images were meant to appear in the reply.)
A HTML reply to a HTML message with embedded images includes those images in the quote in the reply. Attached images (not embedded) are not part of a reply, since there is no need to return attachments to the original sender.
On the second load, it very briefly says "loading message", and then it's replaced with "downloading message" for the rest of the 3 minutes.

I'm not sure I'd want my inbox stored for offline use, it's already over 6 GB according to the Gmail website.

Anyway, you're right, after turning up those values, the 'reply' window now populates the 'to' field and the body text instantly (although it does make all Thunderbird windows unresponsive for 15 seconds until the images appear in the body as well). A second click on the message now just gives a 15-second "loading message" rather than the 3-minute "downloading message". So that narrows down the cause!
(In reply to omgitsraven from comment #8)
> So that narrows down the cause!
That is the cause. Your message is larger than the configured cache size and is constantly retrieved from the server.

All the status indications are correct and the system is also working, albeit very slow.

Use larger thresholds and you'll be fine.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
I feel like "there's no indication that it's still in progress for an entire minute" doesn't really count as "working"? If it were that slow with a progress meter then you could say "it's working albeit very slow"; but I never would have realised that when writing a reply to an email with many images, I'm supposed to walk away from my (seemingly as ready as it's ever going to be) computer and come back later; I only found out because I went to another window to write this bug report while it was happening.
OK, let's reopen this then as enhancement request to show some progress indicator. Maybe when waiting for the reply you still see the "Downloading message..."?
Severity: normal → enhancement
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Summary: Replying to an email with large embedded images causes filling of "To" field and body to be delayed by up to a minute if IMAP folder is not selected for offline use → Replying to an email with large embedded images causes filling of "To" field and body to be delayed by up to a minute if IMAP folder is not selected for offline use and image size is larger than cache limit - no visiual progress indication
That could work. I was also thinking, as a potentially simpler workaround (although maybe open to misuse), when downloading a message larger than your cache size, an alert could pop up saying "this message is too large for Thunderbird's cache, which could cause [instability?], would you like to increase your cache size", which would automatically bump up those values you mentioned if the user agrees.
Good idea, but hard to do, since you find out in the middle of a network operation. Anyway, another enhancement request.
I still think we should increase the cache size ;-)
Attachment #8894055 - Flags: review?(rkent)
Comment on attachment 8894055 [details] [diff] [review]
1382008-cache-size.patch

Review of attachment 8894055 [details] [diff] [review]:
-----------------------------------------------------------------

OK fine.
Attachment #8894055 - Flags: review?(rkent) → review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/0955de442b94
Increase IMAP max. cache entry size from 15MB to 25MB. r=rkent
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Hmm, this bug got closed automatically since I landed a patch increasing the cache size. Obviously this doesn't address the problem of the system not giving any feedback.

I should open a new bug for this.
Target Milestone: --- → Thunderbird 57.0
Filed bug 1388369. Let's change the summary here to reflect what we've done.
Summary: Replying to an email with large embedded images causes filling of "To" field and body to be delayed by up to a minute if IMAP folder is not selected for offline use and image size is larger than cache limit - no visiual progress indication → Increase maximum size of a cache entry from 15 MB to 25 MB
Comment on attachment 8894055 [details] [diff] [review]
1382008-cache-size.patch

We should consider uplift for this.
Attachment #8894055 - Flags: approval-comm-esr52?
Attachment #8894055 - Flags: approval-comm-beta+
Assignee: nobody → jorgk
Attachment #8894055 - Flags: approval-comm-esr52? → approval-comm-esr52+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: