267152 - filepicker component on Linux with modeGetFolder doesn't honour defaultString and displayDirectory properties

Status: RESOLVED EXPIRED

(Firefox :: Shell Integration, defect)

Description

[Giorgio Maone [:ma1]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1

When you open a filepicker dialog (interface nsIFilePicker and class
@mozilla.org/filepicker;1) with mode=nsIFilePicker.modeGetFolder, the text input
box is empty and the "Select" button is disabled no matter if displayDirectory
and/or defaultString is specified. I've observed this behaviour is observed on
Linux, with Firefox 1.0PR and 1.0RC1, with both filepickers (XUL and GTK2).

Reproducible: Always
Steps to Reproduce:
1. open preferences|download
2. check the "Save all files to this folder" radio button
3. select "other" from the adjacent drop-down list

Actual Results:  
The displayed directory is last choosen one (equal to the displayDirectory
property), but the folder name textbox is empty and the "Select" button is
disabled. This prevents confirmation of the default (previous) choice.

Expected Results:  
The textbox should contain the leaf name of the last choosen directory.
This is the behaviour observed on Windows, where you can see a tree view of
directories with the displayDirectory selected and its leaf name displayed in
the textbox. If you simply hit "enter" you confirm the default choice.
The requested behaviour could raise another issue if the UI is not tree-based
but GTK like instead (as in RC1), because the displayDirectory is shown in a
drop-down list and the textbox value is appended to this path. In this case, I
believe the value shown in the drop-down list should be the parent of the
displayDirectory property.

Someone could argue this is not a problem in the proposed test-case (a
preference setting situation), because you can simply cancel the dialog if you
want to confirm previous choice.
This is not true if, for instance, you are using the dialog as a preliminary
step of a multiple save operation (save many items in a folder): the "cancel"
action should be interpreted as an abort message from the user, and this makes
difficult to confirm previous save folder:
user must go up in the directory tree and the re-select the folder, or
alternatively type "./" in the textbox.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.