Open
Bug 364659
Opened 18 years ago
Updated 13 years ago
Open File dialog usability problems: no textual manipulation of pathname, pasting fails, poor representation
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: dsb, Unassigned)
Details
(Whiteboard: [SmBugEvent])
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!)
This is closely related to bug 364662.
Comment 2•16 years ago
|
||
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•16 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
(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.
(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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 6•16 years ago
|
||
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 ?
Version: unspecified → SeaMonkey 1.0 Branch
(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•16 years ago
|
||
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Comment 9•13 years ago
|
||
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).
Updated•13 years ago
|
Whiteboard: [SmBugEvent]
You need to log in
before you can comment on or make changes to this bug.
Description
•