64746 - Need editable directory names in file picker

Status: RESOLVED WONTFIX

(Core :: XUL, enhancement)

Description

[Guy Rixon]

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u)
BuildID:    2000123121

The dialogues for loading and saving files have a text-entry box for the
file-name but only a pull-down menu for the directory name. I find this clunky
and extremely annoying: I frequently have to navigate "window-style up through
six or seven levels of directory and then down through as many levels to get
where I need to be. I'd much rather type in the directory name. It's
particularly painful in the file-load dialogues.  Here, I'd like to type in the
directory name, which I can usually remember, but not the file name, which I
usually forget; i.e. I'd like to quickly get a directory display and then pick a
file from the list. Yes, I know I can type the directory name with the file name
in the file-name box, but it's not quite the same thing.

Reproducible: Always
Steps to Reproduce:
1. Load any file!

Comment 1

[timeless]

jag: yours? and is this a dupe?

Comment 2

[Stephan Niemz]

This was already bugging me several times, too, so confirming.

This applies to Linux (any probably all UNIX systems), too, but unfortunately
there is no "all UNIX systems" in the OS selection.

Comment 3

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 4

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 5

[yiming chung]

add cc

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 94326 has been marked as a duplicate of this bug. ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** Bug 66199 has been marked as a duplicate of this bug. ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

As far as I can tell, this works:

1)  type in a path in the text box for file name
2)  hit enter or the "Open" button....

This is with linux build 2001-08-06-08

Comment 9

[Diego Biurrun]

*** Bug 94326 has been marked as a duplicate of this bug. ***

Comment 10

[Diego Biurrun]

Changing to All/All since we have no general unix platform. This will also be
interesting for windows/mac.

Comment 11

[timeless]

Back to where you came from. Sun Solaris or PC Linux are fine for general *nix. 
this bug applies to the xp filepicker which neither windows nor macos use.

Are you using a windowmanager unrelated to twm?

Comment 12

[William Cattey]

A comment in this bug says that typing in the file picker
text box works as of linux build 2001-08-06-08.

Well, here in build 2001-12-21-08 it does NOT work.

Also, in sites with network filesystems, when you click on ".." to tree
up and down, if you hit a node like "/afs", mozilla hangs unkillable
until it successfully stats hosts around the world for all the /afs cells.

So for some of us, inability to set the text is a REAL NASTY BUG.

Could you please consider elevating this from an enhancement to a bug,
for those of us with distributed filesystem infrastructure?

Comment 13

[Boris Zbarsky [:bzbarsky]]

William, what windowmanager are you using?  Standard Athena sawfish?

Comment 14

[William Cattey]

Yes, that's exactly right.  Totally vanilla Athena Sawfish.
Note also, that at home, on my Vanilla 7.1 system with Sawfish,
the ability to type into the URL picker became impaired with the
November Talkback release.  I wonder if that is related.

The impairment:  URL is highlit, but keyboard input is ignored.
If you click to unhighligh the URL, keyboard input works.

The file-picker behavior is different: No text change whatsoever is
permitted.

Subtle config issue that might be relevant: At home I have all the completion
parameters set to OFF.  At Athena, I had the completely vanilla config enabled.
At home, in file pickers I do NOT get choices.  At Athena, I ONLY get choices.

Comment 15

[Brian Ryner (not reading)]

Ok, so this is purely a UI issue.  There is no loss of functionality because you
can type a directory name in the file name box.  The hang on listing an AFS
directory is covered in bug 113785, unfortunately I don't think there's much we
can do about it (ls will hang as well).

Comment 16

[William Cattey]

Strictly speaking, yes this is a UI issue.
But much like a manhole in the street, it deserves a cover.
If you like I can have some folks here at MIT undertake a formal
usability test, but I expect the user thinks about the file picker like this:

Hmmm, change directory.
Well the filename is down there
The directory is up there
Hmmm I can't edit the directory
Oh look ".." changes the directory.
I'll go ".." up to "/"
Gee, why is Mozilla hung?

This is an EASY hole to fall into, and is neatly
covered if you can edit the directory.

I've asked folks more knowledgeable than I for suggestions
on remedies for the client.

It is strictly true that the same long pause happens in "ls".
But at that point, it's a pretty strong bet that actually stat'ing
all those files is what's intended, and ls is a program easily aborted.

I hear that Open AFS will soon evolve a filesystem-side remedy for this,
but that wont help SMB and NFS users.

What we can, and I think should do now, is make the directory field
directly editable for greater usability, and to put a fence around
the hole to limit the scope of the damage to users until the proper fix
makes its way through the filesystem community.

Comment 17

[jag (Peter Annema)]

You can type the full path in the "filename" field, without the actual filename,
and press enter. This will take you to the correct directory, from where you
then can pick the file you want.

What seems to be needed is a better indication that (full) paths (but not
necessarily with filename) can be typed in the "filename" field.

Comment 18

[William Cattey]

It was an act of desperation on my part (and I have EXTENSIVE
experience) that caused me ever to try modifying the directory by
typing in the filename field.  I had no idea what it was going to do,
and was pleasantly surprised when "/tmp/" did the right thing.  My
expectation was that it would do any number of amalgamations of filename
and directory name.

I strongly suspect that formal usability testing will show that 
people will be extremely resistant to understanding that typing a directory
at the beginning of the filename will do the right thing.  The UI as currently
constructed gives LOTS of cues antagonistic to the understanding you want.

You may discover that making the directory field editable is the simplest
way to get users to do the right thing.  What sorts of additional indication
did you have in mind?

Comment 19

[timeless]

we'd love formal usability testing.

one note, the windows dialogs and even dos dialogs have pretty much always 
allowed this (tested: edit.com, workshop.exe), and i think for some reason 
advanced windows users know this, and basic users never run into a place where 
it matters.

Bryner: wrt the hang, can the directory lookups work on a thread so you could 
abort them?  something like that has to happen on windows because when i go 
into network neighborhood, i can leave it before the list finishes.

... back to the bug summary, there are advantages to an editable current 
directory.  I have directory structures like /home/timeless/mozilla/opt/js 
/home/timeless/comm/mozilla/opt/js /home/timeless/mozilla/js 
/home/timeless/comm/mozilla/js ... being able to manipulate the middle of the 
current directory path would actually be useful to me.  But i think my 
application is at least a bit unusual (although in unix there are lots of 
places where something like this applies, moving form /bin to /usr/bin, from 
/usr/bin to /usr/local/bin ... from ~foo/public_html to ~bar/public_html ...) 
so perhaps it isn't unusual.  usability studies are always welcome.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Attachment: proposed UI

The one problem I see with this UI is that the text in the textbox is always
left-aligned... it would be better if we could right-align it when it's longer
than the box width.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to implement that UI

Fully functional, in case someone wants to test.  (Fixes a little problem we
had with the wait cursor as well.)

Comment 22

[jag (Peter Annema)]

Boris: did you attach the correct image?

Comment 23

[Boris Zbarsky [:bzbarsky]]

Attachment: Real screenshot of proposed UI

Oops.  Obviously I did not.  :)  This should be the correct one...

Comment 24

[William Cattey]

The solution Boris supplied as a demonstration implementation is
PRECISELY the solution I had in mind.

Comment 25

[Boris Zbarsky [:bzbarsky]]

removing blocking of bug 123569.  That bug explicitly says that patches should 
apply to a recent tree to be and I know for a fact that this one does not (the 
code has moved around quite a bit).

Could we please just make a decision on this?

Reasons for needing an editable field at all:
1) Accessing AFS and other network filesystems that have a slow root dir (like
   multiple minutes slow)
2) Access to certain read-protected directories (a dir with -wx permissions
   cannot be read in the filepicker, but one can go to its children directly by
   typing their names.

Pros of having an editable menulist:
1) More discoverable than typing in the filename field

Cons of having an editable menulist:
1) More visual clutter, possibly

Can anyone think of other things in the pros/cons lists?

Comment 26

[Matthew T (active 1999-2002)]

Fine. --> XP Toolkit/Widgets

Comment 27

[Jackie Liu]

*** Bug 343565 has been marked as a duplicate of this bug. ***

Comment 28

[Mats Palmgren (inactive)]

Our built-in file picker was remove in bug 1284391 (sadly).