188394 - Save dialogue: dragging in folder erases filename from "Save As:" field

Status: RESOLVED WORKSFORME

(Camino Graveyard :: Downloading, defect)

Description

[Michael Zajac]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030105 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030105 Chimera/0.6+

Dragging a folder from a finder window into the Save dialogue is a great way to
choose a folder to save in.

But when you do this, the file name in the "Save As:" field at the top is erased. 

On the other hand, when you want to *replace an existing file* on disk, it could
convenient to drag the file in and it replaces the dialogue's default file name.
 This part of the existing behaviour could be useful, but isn't very important.

Reproducible: Always

Steps to Reproduce:
1 Select menu "File -> Save As..." or option-click a link -- the Save dialogue
opens.  Notice that the "Save As:" field contains the file name and has focus,
and the file name (but not suffix) is selected.
2 From an open finder window, drag a folder into the Save dialogue.
3 The dragged folder becomes the displayed folder in the dialogue (excellent!),
but the file name is erased (awww).  The "Save As:" field retains focus and
contains a flashing text-entry cursor.

Actual Results:  
You now have to determine the file name of the document to be downloaded, or
choose a new one, and type it into the "Save As:" field.  Determining the name
may be impossible to do without dismissing the dialogue, if you option-clicked a
link or if the URL is longer than the URL bar.

Expected Results:  
The file name in the Save dialogue's "Save As:" field should have remained there.  

Focus could be shifted to the dialogue's columns view, so that you can use the
keyboard to navigate starting from the dragged folder if necessary.  Or maybe
it's more useful to keep focus on the file name so that you can type a new name
and hit Return to save.

Comment 1

[Jasper]

Confirmed using the 2003081002 NB.

Comment 2

[Josh Aas]

taking

Comment 3

[Josh Aas]

This doesn't happen any more (12/20/04, 10.3.7), and it probably wasn't our
problem since our code doesn't affect that behavior at all.