332110 - Attaching out-of-locale Unicode-named file fails: won't send

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Mike Cowperthwaite]

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.

Comment 1

[Mike Cowperthwaite]

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.)

Comment 3

[Emanuele Bergamini]

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)

Comment 4

[Jungshik Shin]

(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. 

Comment 5

[David :Bienvenu]

the file spec removal work is trunk-only.

Comment 6

[Mike Cowperthwaite]

(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.

Comment 7

[Mike Cowperthwaite]

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.)

Comment 8

[Christian Schmidt]

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.

Comment 9

[Max Giesbert]

the bug still exists for thunderbird 2.0.0.6 and 3.0a with korean letters in the file name. any progress on the subject yet? would be nice to have this fixed...

thx

Comment 11

[Simon Montagu :smontagu]

Attachment: Patch

As the comment implies, the code block I'm removing is unnecessary now that bug 33451 is fixed.

Comment 12

[Gino de Simone]

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

Comment 13

[utf16]

Gino, in case you didn't notice: there's been a patch. Hope it will be included in the next release.

Comment 18

[utf16]

Sorry to bother everyone, but the patch has been proposed four months ago, and I'm still using MS Outlook.

Comment 19

[Magnus Melin [:mkmelin]]

David: ping on the sr for this.

Comment 21

[Simon Montagu :smontagu]

Checked in.

Comment 24

[Noèl Köthe]

Any chance to get that patch in 1.8 branch?

Comment 27

[Michael]

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.

Comment 28

[David Ascher (:davida)]

I'm confused. Thiss bug VERIFIED FIXED and there's a patch?  

Can someone confirm that it's fixed in Shredder nightlies?

Comment 29

[utf16]

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.

Comment 30

[Phil Ringnalda (:philor)]

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.