Closed
Bug 35650
Opened 26 years ago
Closed 14 years ago
Parity - MPOD: attachment icon shows not downloaded, source indicates otherwise
Categories
(MailNews Core :: Backend, defect, P3)
MailNews Core
Backend
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Future
People
(Reporter: laurel, Assigned: Bienvenu)
Details
Using 2000-04-12-06m15 commercial build NT 4.0
Haven't tried other platforms yet, assuming All for now
After getting a message when mail.imap.mime_parts_on_demand is set to true and
mail.inline_attachments is not, the page source doesn't indicate any text such
as "This body part will be downloaded on demand" although the attachment icon in
the message pane shows "not downloaded". The source also displays what looks
like a binary representation (?) of the attachment.
1. Sent a mail message from 4.x with text and a 36KB word document as an
attachment.
2. Received and displayed this message in my seamonkey IMAP mail inbox, that
account having mail.imap.mime_parts_on_demand set to true and
mail.inline_attachments false. The text of the message was displayed in the
message pane correctly.
3. Clicked on the attachment icon in the message pane and saw "Not Downloaded"
next to the attachment name (.doc).
4. Did a View|page Source on the message (type: multipart/mixed) and saw no
indication in the page source that the atttachment would be downloaded on
demand, but rather saw representation of the attachment in the page source
window.
| Assignee | ||
Comment 1•26 years ago
|
||
mail.inline_attachments is ignored. This bug strikes me as invalid. Rich can say
for sure.
Assignee: bienvenu → rhp
Comment 2•26 years ago
|
||
This pref no longer is applicable because of the attachment pulldown menu.
- rhp
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
I was just doing what was indicated in MPOD feature bug #32767 -- it mentions
the inline_attachments pref.
If this bug is invalid, so be it, but in the *tiny* bit of info I have (no
available spec info other than QA test spec) it claims the source should state
something about download on demand -- it doesn't even when the attachment says
it hasn't been downloaded.
I'll pass the testing on to Peter next week.
I agree with Laurel. The way I read this bug is that Mime Part on Demand should
behave similarly to 4.x. Omitting the fact that the user pref
mail.inline.attachment is no longer valid, if I have a mail message that contain
an attachment (not gif/png/jpeg/txt/html) such as a word.doc say 1 megabyte in
size, I expect the Page Source to not display the data stream for the attachment
if it has not been downloaded. In 4.7, the page source displays the text "This
body part will be downloaded on demand.". In 5.0, the same message page source
displays the data stream. I can't find a state where this phase is used.
I am re-openning this bug based on parity between 4.7 and 5.0. If the behavior
is changed, please let me know.
Steps to reproduce problem:
1) Exit Seamonkey
2) Edit the prefs.js file
3) Add the following user pref to the end of the file:
user_pref("mail.imap.mime_parts_on_demand", true);
4) Save the changes
5) Start Seamonkey version 2000-04-24-17-m16 commercial build
6) Open Messenger through the task bar
7) Start a new message
8) Attach aword document greater than 30 k. My test file was 1 MB.
9) Address the mail message to yourself and send it to yourself
10) Retrieve your mail and view the message
11) Click on the attachment icon
It should display the attachment name and indicate that it has not been
downloaded.
12) Select the View menu and choose Page Source
13) Scroll to the attachment portion.
Notice the attachment data stream is displayed.
14) In Communicator 4.7x, view the page source of the same message
Notice that the attachment data stream is not displayed. It says in it
place,"This body part will be downloaded on demand."
I like the 4.7x behavior because, it matches the current state of the message
download.
The behavior is consistent on Mac and linux commercials build 2000-042416-m16.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: MPOD: attachment icon shows not downloaded, source indicates otherwise → Parity - MPOD: attachment icon shows not downloaded, source indicates otherwise
Comment 5•26 years ago
|
||
Hi David,
Hmm...Page source URL's must be getting all of the data. Is there any magic in
the IMAP url handler for this that we may not be doing right now.
- rhp
Assignee: rhp → bienvenu
Status: REOPENED → NEW
| Assignee | ||
Comment 6•26 years ago
|
||
I don't know how that's supposed to work. Moving to m30 - I don't think I can
fix this.
Status: NEW → ASSIGNED
Target Milestone: --- → M30
I have a concern about putting it off to M30. Using today win32 commercial
seamonkey build 2000-04-28-09-m16, it appears that the page source
doesn't download all the attachments.
For example, I attached 3 word documents to a mail message in 4.7 win32 and sent
it to my test accounts. On today 5.0, it downloaded the first attachment but
only a partial of the 2nd attachment and nothing from the third attachment. I
looked in the IMAP log and found that it did not download all the attachments.
So the Page Source doesn't even show the entire message contents.
Comment 8•26 years ago
|
||
moving to future milestone based on bienvenu's last comments. If we think this
is more serious, please reopen and nominate for beta3.
Target Milestone: M30 → Future
QA Contact: trix → stephend
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
QA Contact: stephend → backend
Updated•17 years ago
|
Product: Core → MailNews Core
| Assignee | ||
Comment 11•14 years ago
|
||
We don't have this UI anymore at all, as far as I can tell.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•