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!

jag: yours? and is this a dupe?

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.

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...

updating to new owner. sorry for the spam.

add cc

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

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

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

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

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

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?

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?

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

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.

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).

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.

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.

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?

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.

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.

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

Boris: did you attach the correct image?

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

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

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?

Fine. --> XP Toolkit/Widgets

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

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