370878 - Non-consistent filename after rename in save attachment dialog

Status: RESOLVED INVALID

(Thunderbird :: General, defect)

Description

[Anders Øyvind Sætre]

User-Agent:       Opera/9.10 (Windows NT 5.1; U; en)
Build Identifier: Thunderbird, version 1.5.0.9 (20061207)

During save of an attachment, rename a file on disk. The name in the "file name"-textfield stays the same, but the dialog returns renamed filename.


Reproducible: Always

Steps to Reproduce:
1. Choose "save as..." on an attachment
2 [review]. Rename a file on disk. The file name in "file name"-textfield will change when file is clicked for rename.
3. Click save.
Actual Results:  
"<Renamed file name> already exists. Do you want to replace it?". Notice that the name in "file name"-textfield does not display in message-box, nor does it exist on disk (since you just renamed that filename).

Actual Results Summary: It appears as if the dialog return value changes after a rename, using the renamed file's name without updating the file name-textfield's Text-property.

Expected Results:  
Expected Results: That the FileName-textfield's content is the one used for a save, even after a rename.



Comment: Not sure it this bug is connected to Thunderbird or to the windows save dialog component. Bet you do.

Comment 1

[Mike Cowperthwaite]

I'm not sure if this is Windows-Save-Dialog specific or not.  Notepad doesn't exhibit the bug, and that's as basic a Windows program as there is.  Opera doesn't either.  But Metapad does, so if it's a problem, it's a common one.

It's also not a consistent problem.  I was able to reproduce (2pre-0308) the first time I tried, but not since, including after a restart.

xref bug 355656.

Comment 2

[Wayne Mery (:wsmwk)]

I don't think what I see with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre (.NET CLR 3.5.30729) is a bug