Closed Bug 41569 Opened 26 years ago Closed 26 years ago

make sure MPOD pref is turned on by default

Categories

(MailNews Core :: Networking: IMAP, defect, P3)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Bienvenu, Assigned: Bienvenu)

References

Details

(Whiteboard: [nsbeta2+][will be minus on 6/15])

I keep forgetting to do this, so I'm filing a bug on myself.
ooops...we should have had this turned on while we were at mail connect...shame on us. nominating for beta2.
Keywords: nsbeta2
We don't know what this is..what is MPOD?
Whiteboard: [NEED INFO]
mime parts on demand, not downloading non-inline large imap attachments until the user asks to
Clearing NEED INFO since David has answered. PDT - good to have this so that we can get some good testing of MPOD during beta2 if it's set to the default.
QA Contact: lchiang → pmock
Whiteboard: [NEED INFO]
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
Adding [will be minus on 6/15] per an email from phil.
Whiteboard: [nsbeta2+] → [nsbeta2+][will be minus on 6/15]
fix checked in.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
*** Bug 41399 has been marked as a duplicate of this bug. ***
Fenella, can you help verify? Create a new profile (IMAP) account and look in the prefs file to make sure that this MPOD preference is set to true, I think. David, can you comment on what the preference is? Thanks
QA Contact: pmock → fenella
Unless it's changed, judging from what was said in bug 32767 and bug 35650, the pref would be: "mail.imap.mime_parts_on_demand" However, it does not appear in a new IMAP profile prefs.js file, but that doesn't mean it is not turned ON/True by default and just not shown in prefs.js...
Win32 (2000-07-21-09 M17) Here is what I did: 1. Create a new profile IMAP account, qatest04 2. Access the qatest04 account mail and navigate it a little bit 3. Exit seamonkey 4. Go to the User50, qatest04 directory 5. View the prefs.js file and search for MPOD, mine or keyword "true". "false. Cannot find MPOD related settings. Laurel also tried it, do not anything. Lisa or David, please educate me in this bug.
Ok. I asked Scott. M. the MPOD has been turned on. I see it located in the default directory: netscape 6\defaults\pref\mailnews.js
Status: RESOLVED → VERIFIED
argh, I typed in a long response about how to verify this, and it never showed up in the bug. Ah, dogfood.
Reopening, as both a totally new profile and an imported one don't seem to be exhibiting this feature. It's really, really important because otherwise people have to wait for entire massive attachments to download before they see the text of the message. Also, the message display window does that "non-repainting" thing while the download is going on, which looks horrible. Also, we are downloading the entire message each time any attachment is asked for. This is a separate bug, and one I will file, but its existence makes this one much worse. Gerv
Severity: normal → critical
Status: VERIFIED → REOPENED
Keywords: rtm
Resolution: FIXED → ---
it works fine for me - are you sure the attachments you're talking about aren't inline (e.g., jpegs, html, text)? the second problem is a known, filed bug, so you don't need to file a new one. bug 52260
to elaborate, we always download inline attachments, in both 4.x and 6.0, independent of your MPOD settings.
One is a .tif, the other is a .mp3. So, they shouldn't be inline. I deleted my profile and imported from NS 4.x, and also (in a separate test) said No to the import and created one from scratch for my mail server. In both cases, I have to wait for the entire mail to download. I am using 20001020 Win95. What further tests can I run for you? Gerv
to really see if an attachment is supposed to be rendered inline, you need to look at its content disposition in the mime headers. If the mail was sent by MS Outlook, it will be broken since Outlook sets the content disposition to inline even for things that shouldn't be rendered inline, IMO.
Changing qa assign to myself.
QA Contact: fenella → pmock
Peter - what are your findings?
Mime part on demand is working for me on all platforms using today builds: win32 commercial seamonkey build 2000-102309-mn6 installed on P500 Win98 linux commercial seamonkey build 2000-102309-mn6 installed on P200 RedHat 6.2 macos commercial seamonkey build 2000-102308-mn6 installed on G3/400 OS 9.04
Just to check: you are seeing the message body of a message with a large attachment instantly? Have you checked with an imported, as well as a new profile? If so, then all I can say is <shrug>... Gerv
Gervase, when you look at the message source (View | Message Source) of the message in question, what do the lines that say Content-Disposition look like? If they say in-line, then it's not a problem with MPOD.
OK, fair enough, they do. Is 4.x broken in this respect, as I used it to send the original mails? No matter, this is in fact not an MPOD bug. Re-resolving. Apologies to all. Gerv
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Verifying bug on branch build of win32, linux, and macos.
Keywords: vtrunk
This was fixed way before branching so ok to mark verified; vtrunk not needed.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
If 4.x marks mp3 files as inline, then it's probably because it has an inline handler for files of type mp3 (whereas if Outlook does it, it's because it's broken :-) ) The same is true for tif files, though it might be able to render tif files inline, if tif files are what I think they are.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.