526973 - Mail attachment with non-latin characters in file name is displayed with wrong icon while composing mail

Status: RESOLVED DUPLICATE of bug 415761

(SeaMonkey :: MailNews: Composition, defect)

Description

[hhgygy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

This has been a constant bug since years as I see in bug report
https://bugzilla.mozilla.org/show_bug.cgi?id=255338

The attached *.doc file displays with native doc icon BUT if the file name contains extra characters other than English, it displays a native folder icon.

Reproducible: Always

Steps to Reproduce:
1. Compose new mail
2. Attach a file whose filename contains a diacritical mark (or similar)
3. The file is displayed with a folder icon
Actual Results:  
 The file is displayed with a folder icon

Expected Results:  
 The file ought to be displayed with its native (doc, xls, ppt, pdf etc) icon

Comment 1

[Thomas D. (:thomas8)]

TB equivalent bug (confirming this bug):

Bug 526163 -  Compose Window: Attachment icons inconsistent (wrong icon for attached files with umlauts äöü in filename/filepath)

Comment 2

[:Hb]

Doesn't happen under Linux/Ubuntu.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

Some findings:

1. Compose case:
The icon is set by:
  http://mxr.mozilla.org/comm-1.9.1/source/suite/mailnews/compose/MsgComposeCommands.js#2623
which is basically:
  var item = document.createElement("listitem");
  item.setAttribute("class", "listitem-iconic");
  item.setAttribute("image", "moz-icon:" + attachment.url);
which matches the tree DOM Inspector shows:
  listbox#attachmentBucket listrows listboxbody listitem listcell image

2. Message display case (viewing a message with an attachment):
The icon is set by:
  http://mxr.mozilla.org/comm-1.9.1/source/suite/mailnews/msgHdrViewOverlay.js#1375
which is basically:
  listitem.setAttribute('image', "moz-icon:" + "//" + attachment.displayName + "?size=16&contentType=" + attachment.contentType);

So what's the important difference between 1 and 2? No, it's not the size and contentType parameters, you can add those to the first using DOMI, it doesn't change anything. It's the method of accessing the file (see below).

To compare the cases I created two files with the same content which differed only in one character in their file names. That character was non-latin, I chose 'ä' (German lower case a umlaut). Then I used the DOMI to change the image src. Let's say the files were E:\image.tar.gz and E:\imageä.tar.gz and E:\imagex.tar.gz didn't exist.

Case 1:
image src = moz-icon:file:///E:/image.tar.gz -> archive icon
image src = moz-icon:file:///E:/imageä.tar.gz -> generic folder icon
image src = moz-icon:file:///E:/image%C3%A4.tar.gz -> generic folder icon
image src = moz-icon:file:///E:/image%E4.tar.gz -> generic folder icon
image src = moz-icon:file:///E:/imagex.tar.gz -> "unknown" icon

Case 2: in all cases: archive icon shown. I verified that the contentType parameter takes precedence over the file extension but either way the ä umlaut didn't break anything here.

I guess the moz-icon implementation details are in shared code (libpr0n, nsIconURI.cpp) but I really don't know enough about C++ to be able to check what's going on there. Maybe something related to multi-byte string support (I checked on Win XP with NTFS which uses Unicode).

Comment 4

[Makoto Kato [:m_kato]]

If you cannot reproduce on 2.1 (1.9.3 base), you should dup of bug 415761.

Comment 5

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #4)
> If you cannot reproduce on 2.1 (1.9.3 base), you should dup of bug 415761.

Can reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.10pre) Gecko/20100424 Mnenhy/0.8.1 SeaMonkey/2.0.5pre

Cannot reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100429 SeaMonkey/2.1a1pre

-> marking duplicate. Please only reopen if you can reproduce with a recent trunk nightly.