Closed
Bug 526163
Opened 15 years ago
Closed 15 years ago
Compose Window: Attachment icons inconsistent (wrong icon for attached files with umlauts äöü in filename/filepath)
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(blocking-thunderbird3.1 -)
RESOLVED
DUPLICATE
of bug 415761
Tracking | Status | |
---|---|---|
blocking-thunderbird3.1 | --- | - |
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: polish, regression)
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) 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:1.9.1.5pre) 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.
Reporter | ||
Comment 1•15 years ago
|
||
Comment 2•15 years ago
|
||
Is the subdir a subdir from the desktop ?
Are you using extensions ?
Anything useful in tools-> Error console ?
Reporter | ||
Comment 3•15 years ago
|
||
(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.
Comment 4•15 years ago
|
||
This WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.6pre) 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 ?
Comment 5•15 years ago
|
||
Confirmed here on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•15 years ago
|
||
Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091105 Shredder/3.0pre
umlauts in file name cause the wrong folder icon for attached files.
Summary: Compose Window: Attachment icons inconsistent → Compose Window: Attachment icons inconsistent (wrong icon for attached files with umlauts äöü in filename/filepath)
I also reported it, exactly the same problem with file names containing Hungarian "umlaut"
Bug 526973 is therefore a duplicate of this bug report
Comment 9•15 years ago
|
||
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.
Updated•15 years ago
|
Version: unspecified → 3.0
Comment 10•15 years ago
|
||
Same for me with Win XP:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.5) 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.
Comment 11•15 years ago
|
||
I have this Bug in Windows 7 Pro 64-bit, too!
So it's not restricted to Win XP.
Comment 12•15 years ago
|
||
Comment 13•15 years ago
|
||
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.
Comment 14•15 years ago
|
||
(In reply to comment #13)
> Created an attachment (id=421801) [details]
> sample on winXP
>
TB 3.0 Rus installed
Comment 15•15 years ago
|
||
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.
Flags: blocking-thunderbird3.1?
Reporter | ||
Comment 16•15 years ago
|
||
adding blocking-thunderbird3.1? per request of Comment 15.
blocking-thunderbird3.1: --- → ?
Comment 18•15 years ago
|
||
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>.
blocking-thunderbird3.1: ? → -
Flags: blocking-thunderbird3.1? → wanted-thunderbird+
Comment 19•15 years ago
|
||
(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.
Comment 21•15 years ago
|
||
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
Keywords: regressionwindow-wanted
Comment 22•15 years ago
|
||
(In reply to comment #21)
Tested using STR from comment 5. No obvious checkins jump out at me.
Comment 23•15 years ago
|
||
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.
Comment 24•15 years ago
|
||
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:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
Comment 26•15 years ago
|
||
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).
Comment 27•15 years ago
|
||
Also, I will test this on 3.1b2pre tomorrow. If this isn't occurs on 3.1, this may be bug 415761.
Comment 28•15 years ago
|
||
Using STR in comment #5, now I can't reproduce with
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4pre) Gecko/20100407 Lightning/1.0b2pre Lanikai/3.1b2pre ID:20100407034837
We could close as dupe of bug #415761 I think.
Comment 29•15 years ago
|
||
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.)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•