Very similar to bug 332108. 1) Start a new message composition 2) Attach a file with a Unicode name by dragging from Explorer to attachment panel. 3) Send the file Actual results: 2) filename in panel shows ???? instead of proper name 3) Error: Sending of message failed. Unable to open the temporary file [[<path>\_____.ext]]. ... Expected results 2) filename shown as seen in the Explorer or File Open windows. 3) Transmission without a problem. I first reported this (bug 285073 comment 5) in 2005 with Gecko 1.8b2 versions of TB and Mozilla. Still present in TB 1.5, 2a1-0328 and (importantly) 3a1-0327, which has the patch for bug 162361 in place. I am running an English installation of Windows 2000. I see the same results whether the compose window has the (default) ISO-8859-1 charset or the UTF-8 or UTF-16LE charset. Per Jungshik, this is a problem in the Drag-and-Drop code, hence the dependency. This may also be dependent on bug 33451.
The original symptoms of this bug have changed somewhat: result (2): the filename appears correctly in the Attachment panel However, result (3) still occurs; and it occurs whether the attachment is made by drag-and-drop or by using the Attach command. I thought there was a bug open just for this latter case, but I can't locate it. I'm repurposing this bug for the 'can't send' problem. I'm seeing this now with TB 2b2-0215, 3a1-0214, Seamonkey 1.5a-0210. I think this is Windows-only. > Per Jungshik, this [...] may also be dependent on bug 33451. Bug 234681 was dependent on 33451, but it seems to have been fixed by the patch at bug 359148 which simply replaced a few 'nsCAutoString' instances with 'nsAutoString'. (33451 has a patch checked in since this bug was opened, but for part of the code unrelated to this problem.)
Summary: Attaching Unicode-named file (via drag-and-drop) fails: substitutes '?' characters in name, won't send → Attaching out-of-locale Unicode-named file fails: won't send
Result (3) still occurs vith TB 2.0 Italian, on Win XP PRO Italian, attaching a file with Jap character in file name (and in folder who contain it)
(In reply to comment #1) > Bug 234681 was dependent on 33451, but it seems to have been fixed by the patch > at bug 359148 which simply replaced a few 'nsCAutoString' instances with > 'nsAutoString'. (33451 has a patch checked in since this bug was opened, but > for part of the code unrelated to this problem.) Was bug 234681 fixed in TB 2.0? I guess not. Do NOT expect this bug to be fixed in TB 2.0 unless bug 33451 and 'drag and drop' bug are fixed there, too. Please, concentrate on the trunk.
Depends on: 33451
the file spec removal work is trunk-only.
(In reply to comment #4) > (In reply to comment #1) > > Bug 234681 was dependent on 33451, but it seems to have been fixed by the > > patch at bug 359148 which simply replaced a few 'nsCAutoString' instances > > with 'nsAutoString'. (33451 has a patch checked in since this bug was > > opened, but for part of the code unrelated to this problem.) > > Was bug 234681 fixed in TB 2.0? I guess not. > Do NOT expect this bug to be fixed in TB 2.0 unless bug 33451 and 'drag and > drop' bug are fixed there, too. Please, concentrate on the trunk. I didn't mean to imply anything about the branch. My point was, 234681 was apparently fixed on trunk without a corresponding patch for bug 33451, and I was speculating that perhaps *this* bug could have been fixed on trunk without 33451 getting fixed. Now, of course, there's a lot of new work for 33451 since late March, but I had no way of knowing that was imminent when I posted comment 1.
This bug, at least, was not completely fixed by the work from bug 33451. Testing with 3a1-0527, Win2K. The filename now displays correctly on attaching (whether dragged in or attached via dialog), but the error described in comment 0 step 3 still occurs. (Bug 370761 -- attaching via MAPI -- also still manifests, but I don't think that had the same cause.)
On Linux + Gnome 2.18.2 I experience this problem with Thunderbird 2 and a trunk build, but only when I drag the file from Nautilus, not when I attach it using the Attach File filepicker.
the bug still exists for thunderbird 184.108.40.206 and 3.0a with korean letters in the file name. any progress on the subject yet? would be nice to have this fixed... thx
Created attachment 294665 [details] [diff] [review] Patch As the comment implies, the code block I'm removing is unnecessary now that bug 33451 is fixed.
As of today ( TB 2.009) the bug has not been fixed; may be is nt clear how important is to solve this damn problem. We cannot save attachments with Jap. names. Please be patient, solve it, otherwise we must switch to other products and this would be a shame. Thanks. Gino de Simone
Gino, in case you didn't notice: there's been a patch. Hope it will be included in the next release.
Sorry to bother everyone, but the patch has been proposed four months ago, and I'm still using MS Outlook.
David: ping on the sr for this.
Attachment #294665 - Flags: superreview?(bienvenu) → superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Any chance to get that patch in 1.8 branch?
I really like Thunderbird and will keep using it. However, it would be great if this patch could be compiled into an update soon. It would make Thunderbird that much better.
I'm confused. Thiss bug VERIFIED FIXED and there's a patch? Can someone confirm that it's fixed in Shredder nightlies?
Oh, yes, it's fixed. It's been some time I've been switching to beta version every time I need to send an attachment.
But the fix depended entirely on bug 33451, which is absolutely not going into Tb 2.x, so unfortunately this is just another reason why we need to hurry up and ship 3.0.
You need to log in before you can comment on or make changes to this bug.