Closed Bug 32767 Opened 20 years ago Closed 20 years ago

[FEATURE] IMAP protocol work for Mime Parts on Demand

Categories

(MailNews Core :: Backend, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Bienvenu, Assigned: Bienvenu)

References

Details

(Whiteboard: ETA 4/05/00)

I need to get the IMAP protocol and parsing code working for Mime Parts on 
Demand.
accepting, adding dependency.
Blocks: 17794
Status: NEW → ASSIGNED
Target Milestone: ---
It's going pretty well, but I'm worried that there will be lots of edge cases.
Priority: P3 → P1
Whiteboard: ETA 3/31/00
Target Milestone: --- → M15
sigh, this just got a lot harder. The way we were downloading imap attachments 
was to download the whole message and run it through the mime parser. Pretty 
wasteful when the imap server's got a perfectly good mime parser all ready to 
use. I'm going to have to rearrange all the attachment downloading code and 
write special code for imap.
Whiteboard: ETA 3/31/00 → ETA 4/05/00
ugghh...yuck.
downloading imap attachments seems to work now. There are some remaining bugs 
(e.g., message bodies not showing when we download parts on demand, which I'll 
look into to see if it's something systemic before filing bugs).
turns out that the message bodies not showing happens when the message is 
multi-part alternative. 4.5 would not do MPOD on multi-part alternative 
messages, so I must have lost some logic somewhere.
i think you've lost more than some of your logic.....


=)
moving to P2. This is pretty much working, though not turned on yet by default. 
If you set the following pref:
user_pref("mail.imap.mime_parts_on_demand", true);

and make sure that user_pref("mail.inline_attachments" is NOT set to true, it 
should work.
Priority: P1 → P2
this is fixed, but you have to turn the pref on. I'll change the default after 
m15, but QA can start testing now.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
QA Contact: lchiang → pmock
This seems to be basically working in 2000-04-12-06m15 commercial build on NT
4.0.  Any specific issues I find I'll log separately.

I need to check in other platforms, too, and will update comments accordingly.
I will ultimately leave this bug resolved so it will be more visible to Peter
when he returns from sabbatical next week... I'll leave the full feature testing
to him. Yay.
mail.inline_attachments is now obsolete. there was a bug where I was paying 
attention to it in MPOD, which is why I added the comment I did. That bug is 
fixed, and the pref is now completely ignored.
Verified as fixed on win32, macos, and linux using the following builds:
 win32 commercial seamonkey build 00042009-m16 installed on Dell P500, Win98
 macos commercial seamonkey build 00042011-m16 installed on G3/400, MacOS 9
 linux commercial seamonkey build 00042409-m16 installed on P200, RedHat 6.1

Enabling the user pref "mail.imap.mime_parts_on_demand" to be true is working. I 
can attach an large file such as adobe acrobat file (that does not display 
inline) does not get downloaded when viewing the message.

The mail user pref "mail.inline_attachment" currently does not work. In 4.x it 
was used to set the view menu option to display attachments such as jpeg or gif 
inline. This menu option is currently disabled and by default displays 
attachments inline. In 4.x, I would have attached a large jpeg/gif/png file to a 
mail message then sent the mail message to myself. Upon viewing the mail 
message, I would check the Page Source and find the mpod phase "This body part 
will be downloaded on demand.")  I looked but could not find the bug that 
bienvenu was referencing.

Verifying bug as fixed.
Status: RESOLVED → VERIFIED
"mail.inline_attachment" is obsolete, and the feature doesn't exist in 6.0, for 
imap or for any kind of mail/news message.
Thanks David for the confirmation. :)
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.