Closed
Bug 557469
Opened 15 years ago
Closed 15 years ago
Attachment clip appears then disappears and attachment is not visible (multipart/mixed, but mail-boy-part only, no attachment)
Categories
(MailNews Core :: Attachments, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 479017
People
(Reporter: gilles.poulleau, Unassigned)
Details
(Keywords: qawanted, testcase, Whiteboard: [needs MIME analysis] [dupeme])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
When receiving emails from the equipment, the attachment clip is first displayed, indicating the existence of an attachment.
When the message is selected, the attachment clip disappear and no attachment is shown.
Extracting the email and extracting the attachment with an external email decoder works fine.
Reopening the previously saved email in eml format is still negative.
Safe-mode made no change.
No errors in Error console.
Reproducible: Always
Steps to Reproduce:
1. Open the attachment filed with the bug
2.
3.
Actual Results:
No attachment displayed
Expected Results:
Attachment visible
Reporter | ||
Comment 1•15 years ago
|
||
Comment 2•15 years ago
|
||
I see this on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 ID:20100317103207.
What mail agent was this sent with? Presumably not Thunderbird.
I'll have to pass this on to someone who knows more about MIME's fiddly bits than I; it may be expected behavior in this case. (In particular, the content-id header on the attachment looks suspicious to me -- if it has a content-id, isn't it supposed to be used as a source for inline pictures or the like?)
Component: General → Attachments
Keywords: qawanted
Product: Thunderbird → MailNews Core
QA Contact: general → attachments
Whiteboard: [needs MIME analysis]
Reporter | ||
Comment 3•15 years ago
|
||
The mail is sent by an air conditioning control hardware.
The manufacturer is far from a big company and they probably just checked their mail with an external look...
I have no skills in decoding MIME headers myself. Therefore, I cannot validate it.
The only thing I can think of, is that if others mail agents or mail decoders can cope with a perhaps badly formatted header, why Thunderbird would'nt have the same indulgence ?
Updated•15 years ago
|
Attachment #437258 -
Attachment mime type: message/rfc822 → text/plain
Comment 4•15 years ago
|
||
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=multipart%2Fmixed shows a few related issues.(In reply to comment #2)
>
> I'll have to pass this on to someone who knows more about MIME's fiddly bits
> than I; it may be expected behavior in this case. (In particular, the
> content-id header on the attachment looks suspicious to me -- if it has a
> content-id, isn't it supposed to be used as a source for inline pictures or the
> like?)
Wada San can you have a look please ?
Keywords: testcase
Comment 5•15 years ago
|
||
Mail structure is as follows.
> content-type: multipart/mixed; boundary=--boundary_15_ca3d50eb-cbf4-4537-aa92-5340642659f9
>
> (Part 1 of multipart/mixed)
> ----boundary_15_ca3d50eb-cbf4-4537-aa92-5340642659f9
> content-type: multipart/alternative; boundary=--boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc
>
> (Part 1.1 of multipart/alternativa)
> ----boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc
> content-type: multipart/related;
> boundary=--boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7; type="text/html"
>
> (Part 1.1.1 of multipart/related)
> ----boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7
> content-type: text/html; charset=utf-8
> content-transfer-encoding: base64
>
> PGh0bWw+PGJvZHk+PEZPTlQgZmFjZT0iQXJpYWwiIHNpemU9ND4yMi8wMy8yMDEwIDA5OjI2
> (snip)
> ZDpQaWMxIj48YnI+PC9ib2R5PjwvaHRtbD4=
>
> (Part 1.1.2 of multipart/related, embedded image of HTML mail)
> ----boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7
> content-type: image/jpeg
> content-transfer-encoding: base64
> content-id: <Pic1>
>
> iVBORw0KGgoAAAANSUhEUgAAAZAAAAEsCAYAAADtt+XCAAAAAXNSR0IArs4c6QAAAARnQU1B
> (snip)
> FnBZ4P8Bd18WeKsyHD8AAAAASUVORK5CYII=
> ----boundary_17_c7558830-2249-403f-a7dd-5f334fb19fc7--
>
> (Part 1.2 of multipart/alternativa)
> ----boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc
> content-type: text/plain; charset=utf-8
> content-transfer-encoding: base64
>
> MjIvMDMvMjAxMCAwOToyNiA6IETDqWJ1dCBhbGFybWUgYmFzc2UgKDI2LDkgJSkgc3VyIGwn
> dW5pdMOpIHN1cnZlaWxsw6llIEhSIFNhbGxlIFNhdHVybmUgKDEyMCBSZEMp
> ----boundary_16_28c14e03-4fb9-45be-aeca-4060be3cc9bc--
>
> (End of Part 1 of multipart/mixed, no other part of multipart/mixed, because close boundary)
> ( mail-body = part of multipart/alternative. No part of attachment in multipart/mixed mail)
> ----boundary_15_ca3d50eb-cbf4-4537-aa92-5340642659f9--
(1) Because multipart/mixed mail(it's for mail-body part + attachment parts), Tb initially displays attachment icon upon initial download(no additional mail structure analysis mainly for performance reason).
(2) Tb analyzes mail structure upon mail display request.
- No attachment part in main multipart/mixed mail.
- Because multipart/related part in multipart/alternative part(text/html part
+ image/html part for embedded image) is properly structured,
there is no non-diplayable part due to incorrect/malformed mail structure.
(3) There is no part which is to be displayed in attachment box for Tb.
=> Mail initially has attachment icon, but finally has no attachment icon.
DUP of already opened bug report at B.M.O.
Whiteboard: [needs MIME analysis] → [needs MIME analysis] [dupeme]
Updated•15 years ago
|
Summary: Attachment clip appears then disappears and attachment is not visible → Attachment clip appears then disappears and attachment is not visible (multipart/mixed, but mail-boy-part only, no attachment)
Comment 6•15 years ago
|
||
Thank you Wada !
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 7•15 years ago
|
||
I'd like to point out that in this case, as it's not the same for the 479017 bug,
there is here a real attachment with a real file in it which SHOULD be displayed...
Comment 8•15 years ago
|
||
(In reply to comment #7)
> there is here a real attachment with a real file in it which SHOULD be
> displayed...
gilles.poulleau@ias.u-psud.fr(bug opener):
Where can we see mail ATTACHMENT part in your mail sample?
Which part is the "real atacchment" in your mail sample?
Do you understand what multipart/related means?
Was image/jpeg part with content-id: <Pic1> displayed as attachment in attacment box?
(I didn't check whether HTML points the part by <img src="cid:Pic1"> or not.)
You need to log in
before you can comment on or make changes to this bug.
Description
•