364659 - Open File dialog usability problems: no textual manipulation of pathname, pasting fails, poor representation

Status: UNCONFIRMED

(SeaMonkey :: UI Design, defect)

Description

[Daniel B.]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 SeaMonkey/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 SeaMonkey/1.0.6

The Open File dialog doesn't let the user perform normal textual manipulations 
of the current pathname.  There's no text field containing the current pathname,
so the user cannot:
- delete a character from the pathname
- insert a character into the pathname
- paste some characters into the pathname
- select a range of characters to delete from the pathname

Even selecting just a whole pathname somewhere on the display and middle-
clicking on the Open File dialog to paste it doesn't work.  (Such middle-
clicking works works in a browser window, displaying that file.)  

Finally, the Open File dialog doesn't display the pathname very recognizably.
Specifically, it doesn't display it with pathname segment separate characters
("/" on Linux).


Reproducible: Always

Steps to Reproduce:
Regarding textual manipulations:
A1. Bring up the Open File dialog
A2. Notice that there's no text field containing the pathname, and
    notice that you can't edit the current pathname to get to some
    other pathname you might  want.
    (Imagine viewing file a1234.html and trying to get to 
    a corresponding  file b1234.html, or viewing file 
    /xxx/one/yyy/x.html and trying to get to 
    /xxx/two/yyy/x.html.)

Regarding pasting:
B1.  Bring up the Open File dialog.
B2.  In some window (e.g., an xterm), drag to select a full pathname.)
B3.  Middle-click in the Open File dialog.
B4.  Notice that nothing happens, specifically, that the Open File dialog does
     not:
     - switch to displaying the pathname of the directory of the pathname you 
       selected, 
     - list the files within that directory, and
     - select (highlight) the file corresponding to the pathname you selected.

Actual Results:  
See steps A2 and B4.

Expected Results:  
Seamonkey should let the user perform normal string operations on the pathname
string.

(Even if Seamonkey lets the user specify the pathname by traversing the
filesystem hierarchy (e.g., the per-segment buttons and the list of simple
names of files in the currently selected directory), it should still let
the user edit the pathname.

Seamonkey should also work with standard X11 cut and paste.

(Seamonkey should be at least as good as old Netscape 4.7!)

Comment 1

[Daniel B.]

This is closely related to bug 364662.

Comment 2

[Tony Mechelynck [:tonymec]]

What is the status of preference ui.allow_platform_file_picker in about:config ? Does it make a difference to the bug if you toggle that pref?

-- Workaround: Instead of File -> Open, type or paste a file: URL into the URL bar. Prefix the pathname or pathfilename by file:///, use a forward slash as path separator even on Windows, and replace any embedded spaces by %20.

Comment 3

[Tony Mechelynck [:tonymec]]

No reply in 3 weeks to the question at top of comment #2

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041201 SeaMonkey/2.0a1pre

WFM using the XUL dialog (ui.allow.platform_file_picker set to false):
- the path is displayed at top in full (with / separators on Linux) in the rolldown box (rolling down shows its successive parents up to the / directory)
- pasting a directory (using Ctrl-V) in the input box at bottom, then clicking Open or hitting Enter, opens that directory in the same dialog.
- pasting a path+filename, editing it, then clicking Open or hitting Enter, opens the (edited) filepathname if it exists.

Resolving WORKSFORME.

Comment 4

[Daniel B.]

(In reply to comment #2)
> What is the status of preference ui.allow_platform_file_picker in about:config

It is set to true.

> ? Does it make a difference to the bug if you toggle that pref?

Yes.  

With ui.allow_platform_file_picker true, I get what I reported above.

With ui.allow_platform_file_picker false, I get a different Open File
dialog box.

It seems better, but has some of the same usability problems:

The directory name is displayed in a pulldown list that is not a 
combo box (if that's right term for a combination of a pulldown list
and an editable text box).  Therefore, one still can't edit the
directory portion of the pathname.  (One has to navigate around the
directory hierarchy, even when editing just a few characters is all
that is wanted.)

The "Show hidden files and directories" control does not retain its
state across invocations of the Open File dialog, so to see so-called
"hidden" files, one has to re-click it each damn time.

Comment 5

[Daniel B.]

(In reply to comment #3)

> WFM using the XUL dialog (ui.allow.platform_file_picker set to false):
>...
> - pasting a path+filename, editing it, then clicking Open or hitting Enter,
> opens the (edited) filepathname if it exists.

That addresses editing a NEW (newly pasted) pathname.

That does not address editing the directory pathname that _initially_ appears
in the rolldown box.

I reported:

> The Open File dialog doesn't let the user perform normal textual manipulations 
> o[n] the current pathname.  There's no text field containing the current
> pathname, so the user cannot:
> - delete a character from the pathname
> - insert a character into the pathname
> - paste some characters into the pathname
> - select a range of characters to delete from the pathname

You wrote:
> Resolving WORKSFORME.

How can you claim it works for you?  Your comments say NOTHING about 
editing the initial pathname.  They only address editing a pathname
pasted into the text box, which has little to do with the bug I 
reported.

Reopening.

Comment 6

[Serge Gautherie (:sgautherie)]

Daniel,

(In reply to comment #0)

> Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8)
> Gecko/20061029 SeaMonkey/1.0.6

SeaMonkey v1.0.x is not supported anymore.

Can you reproduce with SeaMonkey v1.1.9 ?

> (Seamonkey should be at least as good as old Netscape 4.7!)

Are saying that all this worked as you request in Netscape v4.7 ?

Comment 7

[Daniel B.]

(In reply to comment #6)
> Daniel,

> SeaMonkey v1.0.x is not supported anymore.

The reported problem is still a problem in SeaMonkey 1.1.9.



> Can you reproduce with SeaMonkey v1.1.9 ?

Yes.  Both comment #4 and comment #5 certainly reflect a 1.1.x version
(I upgraded to 1.1.9 on 2008-05-07, but I don't recall whether before
or after reporting those comments), and, in any case, right now 1.1.9 
seems the same (the directory portion of the file pathname is not 
editable).


> > (Seamonkey should be at least as good as old Netscape 4.7!)
> 
> Are saying that all this worked as you request in Netscape v4.7 ?

Yes.  Netscape 4.7 allowed editing the directory pathname.

The key element was that the directory pathname appeared in a text box
at the top of the Netscape's dialog box for opening files.  You could
easily edit, copy, paste into, etc., that text box and pathname.


Details:

If I recall correctly:

The directory name appeared in a text box at the top of the open-file 
and save-file dialog boxes.  You could cut from, paste into, and edit
the text.

(The text was not just the full directory pathname but also a wildcard 
expression to select files within the directory.  Normally (when you 
first opened the dialog, and unless you manually changed it) the 
wildcard expression was simply an asterisk.)

Below that was a list box that listed file names.  The directory 
pathname portion (from above) controlled which directory's files were 
listed in it.  (The wildcard portion (from above) controlled which 
files within the directory were listed.)

If you edited the pathname portion of the directory name text, a 
different directory's files would be listed.  (You had to trigger the 
update manually by clicking a Filter button.)  (Similarly, if you 
modified the wildcard part, a different subset of files would be listed.)  

I'm pretty sure there was also a second list box to the left of the 
files list box that listed only directory names (".." and child 
directories), for easy navigation up and down the directory tree.

Finally, at the bottom was a text box for display, entering, and/or
editing the text of a file simple name (not a full pathname).

(I don't recall whether pasting a directory name or full pathname into 
the file simple name text box worked (distributing the directory 
portion into the directory name box).)



Please note that I'm _not_ saying that SeaMonkey's open-file dialog 
box should be just like Netscape 4's.

I'm just saying that it should support the key functionality that is
missing.

The main missing functionality is the ability to edit, cut from, and
incrementally paste into directory pathname strings. 

If the current pull-down list were changed to a combo box (the text 
would be re-parsed, to update the pull-down list and to re-populate 
the file list), I think that would provide the requested functionality.


(Of course, I wouldn't mind if traversing up to the parent directory 
were also easier--e.g., if the "up" button were on the left, closer to 
the file names (to make visually scanning from the column of file names
to the "up" button, and moving the pointer cursor, easier and quicker),
or if the file name list started with an ".." or "up to parent" entry
(though I assume other would consider that counterintuitive to many 
users).)

Comment 8

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 9

[[:Aleksej]]

Closest to this bug I've found filed for GtkFileChooser: https://bugzilla.gnome.org/show_bug.cgi?id=349502 (or at least schorsch's comments there).