User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20091102 Shredder/3.0pre See screenshot. Reproducible: Always Steps to Reproduce: 1. open compose window 2. attach file from subdir (not Desktop!) by clicking attach button or drag&drop 3. Actual Results: Folder icon appears next to file name Expected Results: Icon representing the file type should be displayed next to the file name.
Is the subdir a subdir from the desktop ? Are you using extensions ? Anything useful in tools-> Error console ?
(In reply to comment #2) > Is the subdir a subdir from the desktop ? No, it was a subdir of "eigene dateien". > Are you using extensions ? yes: nntpthreads and Custom Buttons. > Anything useful in tools-> Error console ? nothing, error console is empty I think it is related to the name of the folder containing the attachment: if the name contains "umlaute" (e.g. öäü) , the icon is wrong and instead of a file type icon a folder icon is shown.
This WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:184.108.40.206pre) Gecko/20091103 Shredder/3.0pre. I have a pdf documenet ina folder names ümlaut - when I attach the document, the icon is the proper one. Aureliano can you check on XP/Vista please ?
Confirmed here on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20091103 Lightning/1.0pre Shredder/3.0pre ID:20091103032145 STR: 1. create a folder in C:\Temp\Test 2. create an empty *.txt file on C:\Temp\Test named ümlaut.txt 3. create a new message and attach file C:\Temp\Test\ümlaut.txt using attach button on toolbar of compose window: behaves as descrive in comment #0.
Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20091105 Shredder/3.0pre umlauts in file name cause the wrong folder icon for attached files.
I also reported it, exactly the same problem with file names containing Hungarian "umlaut"
Bug 526973 is therefore a duplicate of this bug report
Thanks hhgygy for your comments. Bug 526973 is systematically not a duplicate, because it is reported against SeaMonkey. We keep TB and SM bugs separate. They might actually have the same cause in the core.
Same for me with Win XP: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20091204 Thunderbird/3.0 Creating an attachment from a file like "täst.png" shows always a folder icon. (Tested with Charamel and Standard template). In the german TB - forum (http://www.thunderbird-mail.de/forum/viewtopic.php?f=31&t=44410) it seems that only Win XP has this problem. Users with Vista or Windows 7 could not reproduce this.
I have this Bug in Windows 7 Pro 64-bit, too! So it's not restricted to Win XP.
Created attachment 421801 [details] sample on winXP I got same error. What I do: - create directory "C:\Привет" (Привет is hello in Russian) - put same file in this directory and in D:\TEMP - attach both files to new message - file which have non-ascii characters in full path, doesnt have JPEG icon but folder icon I mean, there are some function exists, which split file extension from full path for looking icon in registry and which dont know (albanian :) non-ascii charactes. So on this files function failed and attachment got default (folder) icon.
(In reply to comment #13) > Created an attachment (id=421801) [details] > sample on winXP > TB 3.0 Rus installed
This bug will regularly affect a lot of users (from all non-English-ascii countries) in daily use. Although this bug doesn't hurt functionality, I am finding this extremely irritating in daily use: Subconsciously, I keep wondering if Thunderbird will send my folders because most times when I attach a file, it's shows up wrongly with the folder icon. It also makes it much harder to parse which of several files of different types have already been attached or not. What I'm trying to say is that this bug is quite visually exposed and will be frequently met by many users, who might jump to the wrong conclusions about the quality of Thunderbird. -> Nominating blocking 3.1 Otherwise, please mark wanted-thunderbird+ I don't understand why we seem to use different functions for extracting the icons for composing and received/saved messages, where we get all the icons right.
adding blocking-thunderbird3.1? per request of Comment 15.
This does seem like an somewhat annoying bug, but I don't think it quite rises to the level of a blocker, since if it were the last bug standing, we wouldn't hold for, so setting blocking-, but wanted-thunderbird+. My suspicion is that this bug is likely easy to fix if we can find the problem. I notice that the regression / regressionwindow-wanted keywords are set, but I don't see any comments explaining why this is believed to be a regression. That said, if it is, if someone is willing to spend the time to track down when the regression occurred, that's likely to make this bug be fixed a bunch sooner. Instructions for finding regression windows are at <http://quality.mozilla.org/documents-home/bugs-docs/bug-triaging-guidelines/finding-regression-windows>.
(In reply to comment #18) > This does seem like an somewhat annoying bug, but I don't think it quite rises > to the level of a blocker, since if it were the last bug standing, we wouldn't > hold for, so setting blocking-, but wanted-thunderbird+. My suspicion is that > this bug is likely easy to fix if we can find the problem. > I believe that the status of the blocking needed - this will prevent the developers from releasing version, complete of unfinished features. I think it is better to have a program with 5 safe working features than a program with 50 non-debugged.
Regression range: works: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1a2pre) Gecko/20080827031724 Shredder/3.0b1pre 2008-08-27-03-comm-central broken: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1a2pre) Gecko/20080828032200 Shredder/3.0b1pre 2008-08-28-03-comm-central http://hg.mozilla.org/comm-central/pushloghtml?startdate=2008-08-27+02%3A00%3A00&enddate=2008-08-28+04%3A00%3A00
You're missing the mozilla-central changes: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-27+00%3A00%3A00&enddate=2008-08-28+08%3A00%3A00 If this is windows only, then it could point to some of the "reduce narrow Windows API calls" changes.
Doesn't seem to apply for me in linux. No attachments get icons at all. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20100227 Thunderbird/3.0.3
Does anyone test whether this can still reproduce on 3.1b2pre (1.9.2 or 1.9.3)? As long as I know, there is same problem on Firefox 3.5 (1.9.1 base). When the save path is non-ASCII such as Japanese, the icon for file extension disappears in "Downloads" window. But it doesn't occur on Firefox 3.6 (1.9.2 base).
Also, I will test this on 3.1b2pre tomorrow. If this isn't occurs on 3.1, this may be bug 415761.
Using STR in comment #5, now I can't reproduce with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:188.8.131.52pre) Gecko/20100407 Lightning/1.0b2pre Lanikai/3.1b2pre ID:20100407034837 We could close as dupe of bug #415761 I think.
Thanks, Aureliano! When I test on 3.1b2pre today, I cannot reproduce this. This is bug 415761. (It seems to be a=1911- by beltzner. If need a fix for 1.9.1 branch, anyone should set approve flag again.)