64787 - sending / reading .wav file attachments behaviour differs from 4.x

Status: RESOLVED DUPLICATE of bug 57297

(MailNews Core :: Composition, defect)

Description

[(not reading, please use [e-mail] instead)]

when I send the same .wav file from 4.x and from 6.x:

1) when using 4.x to read mail, both attachments show up as type "audio/x-wav"

2) when using 6.x to read mail, the attachment sent from 4.x has the right type
("audio/x-wav") and the attachment sent from 6.x has "application/octet-stream"

cc'ing mscott, who might already own this bug.

Comment 1

[Becki Sanford]

Is this the same as http://bugzilla.mozilla.org/show_bug.cgi?id=57297  ??

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

I'm pretty sure it is, but I won't mark it till I'm 100% sure.  Mscott?

Comment 3

[fenella]

To Esther ..

Comment 4

[Becki Sanford]

This problem seems to occur when the attachment has NOT been downloaded with the
message.

Comment 5

[Becki Sanford]

Thought I should add a little more background information.  Via the
Edit/Preferences/Navigator/Helper Applications dialog, I've defined a helper
application for "audio/x-wav" to be associated with file extensions "wav".  This
information is stored in my ~/.mozilla/default/mimeTypes.rdf file just fine.

The problem occurs when nsMsgComposeAndSend::AddCompFieldLocalAttachments()
calls nsExternalHelperAppService::GetTypeFromExtension() to get the content
type.  This function only looks for the file extension in the MIME cache and
plugins.  From what I can decipher, the MIME cache was loaded with just the
default MIME entries, content type mappings that are handled internally by
Mozilla; none of the helper applications defined by the user are in the cache so
the hash key lookup fails for the "wav" extension.  This causes the previously
mentioned compose function to default to "application/octet-stream" for the
content type.

It seems to me that there's some missing logic in nsExternalHelperAppService but
maybe it's just tucked away somewhere else...

Comment 6

[Becki Sanford]

nsExternalHelperAppService::GetFromMIMEType() calls
GetMIMEInfoForMimeTypeFromDS() to check the mimeTypes.rdf file when it doesn't
find the requested content type in the hash table.  Seems like similar logic is
needed in nsExternalHelperAppService::GetFromExtension()...

Comment 7

[Jean-Francois Ducarroz]

reassign to mscott, should be same problem as 57297

Comment 8

[Wayne Mery (:wsmwk)]

since two people have said it, duping