Closed Bug 12707 Opened 25 years ago Closed 22 years ago

[xul] directory listings can't go to higher level directories

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 33684
Milestone:
mozilla1.1alpha

People

(Reporter: paulmac, Assigned: bbaetz)

References

Details

(Keywords: helpwanted, Whiteboard: [xul dirviewer])

Attachments

(3 files)

This patch adds a button to the top of the ftp listing to Change up.
752 bytes, patch
Details | Diff | Splinter Review
Patch with the missing slash added
753 bytes, patch
Details | Diff | Splinter Review
Patch with Blake's and Timeless' changes
1.29 KB, patch
Details | Diff | Splinter Review 
On 4.x, when browsing your local directories, you can go to a higher level
directory by clicking on "Up to a higher level directory" We don't have that
option yet in seamonkey.

p.s. let me know what component we should be filing these under.
Target Milestone: M10
Status: NEW → ASSIGNED
Summary: file:// URL's - can't go to higher level directories → [HELPWANTED] file:// URL's - can't go to higher level directories
This is purely a guess, but if the code to handle moving up a level in a
directory tree is simply missing (as yet), this would probably also explain the
behaviour in bug 12749, where attempting to move up a level by trimming the
file:/// URL generates an unknown file type error. If so, the code that fixes
this bug should be tested to see if it fixes 12749.
Summary: [HELPWANTED] file:// URL's - can't go to higher level directories → file:// URL's - can't go to higher level directories
Whiteboard: [HELP WANTED]
*** Bug 14426 has been marked as a duplicate of this bug. ***
bulldozer to M12
Assignee: waterson → don
Status: ASSIGNED → NEW
Target Milestone: M12 → M15
don: can you find an XPApps person to make this UI happen? thanks.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Assignee: don → valeski
I think this is a newlib bug.  valeski?
Assignee: valeski → donm
don, waterson currently owns the directory listing code which file and ftp urls
are using. I'm under the impression that someone in your group is going to be
taking this over. the dir listing code handles tree view presentation and pass
through calls to the webshell.
Assignee: donm → don
who the hell is donm
QA Contact: paulmac → shrir
setting shrir as qa
Keywords: helpwanted
changed summary from "file:// URL's - can't go to higher level directories"
Summary: file:// URL's - can't go to higher level directories → directory listings can't go to higher level directories
*** Bug 22777 has been marked as a duplicate of this bug. ***
Whiteboard: [HELP WANTED]
*** Bug 30995 has been marked as a duplicate of this bug. ***
*** Bug 32673 has been marked as a duplicate of this bug. ***
*** Bug 31676 has been marked as a duplicate of this bug. ***
*** Bug 31676 has been marked as a duplicate of this bug. ***
Move to M16 for now ...
Target Milestone: M15 → M16
Reassigning for Don
Assignee: don → law
Target Milestone: M16 → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
Status: NEW → ASSIGNED
*** Bug 44546 has been marked as a duplicate of this bug. ***
Keywords: 4xp
Keywords: mostfreq
*** Bug 56803 has been marked as a duplicate of this bug. ***
adding dataloss, as the ".." directory is being lost -- which makes it appear
that the directory has no parent.
Keywords: dataloss
This is not dataloss.

The correct fix would probably be to give it a two pane view, or to stick the 
second pane into the sidebar (like ie does it).

Blake do you think you [know someone who] could make such a panel?
Keywords: dataloss
We don't need a second pane to give the option of moving up to the parent
directory.  A 2-pane view showing directories might be nice, but then we'd still
have the bug of having to show the parent in the directory pane.

This bug makes it a headache to grab mozilla builds now that there are separate
trunk and branch build (go to my LATEST bookmark, click in the urlbar, do END
and backspace back to the last /).  Is it really that hard to add a line saying
"Parent Directory"?
Personally i'd want to get to an arbitrary ancestor, and I bet you would too.
The current architecture looks like a tree, to fix it would require an 
additional object, which might as well be a special tree that lists all 
ancestors
Sure, that would be nice, but I'd be happy with having the old interface 4.x
always had of just letting me get to the parent by adding a single line "Parent
Directory".  I can always go up again after loading the parent directory.  The
current interface offers no way to do that short of editing the urlbar.
for a 4xp mostfreq, this seems like a relatively straightforward bug to have
died such a sorrowful death.

is there some way to allow an added ".." element to appear at the top of the
file list at an ftp site, that would simply link to the parent directory?  even
if it would mean re-rendering the file list tree?

*** Bug 62660 has been marked as a duplicate of this bug. ***
*** Bug 62660 has been marked as a duplicate of this bug. ***
Adding 'ftp' to summary, since the XUL is the same for file:// and ftp://
Summary: directory listings can't go to higher level directories → ftp and directory listings can't go to higher level directories
One-click access to an arbitrary ancestor would maybe be nice, but getting to
the immediate ancestor is imperative.  Also, "Go up one directory" doesn't
require the query time that "recursively query to the top of the tree over a
slow ftp link" does.
This madness has gone on long enough. Nominating mozilla0.8. This is a truly 
silly bug to have knocking about :-)

Gerv
Keywords: mozilla0.8
adding self to CC

This is a silly bug to remain unsolved for so long (since Aug 1999).
Added self to CC ; agree it should be killed (simply); am newby but would try to
help. Will get in touch; please get in touch.
qa: tever
QA Contact: shrir → tever
The patch I just attached creates a button on top of the Tree listing that says
"Change Directory Up". Minimal javascript functionality is included, and it even
does the right thing when you're at the root directory and you hit the button.

More buttons could be added for more ftp specific functionality. This may beg to
be a popup toolbar like the Form Toolbar.

Although, it seems it might be better to not delete the ".." directory, which
appears to happen here:

http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsFTPDirListingConv.cpp#784

Although modifying that line doesn't magically add back the ".." entry. cc'ing
valeski as he owns that line of code, and might have some insight into how to
get the ".." directory to reappear in the ftp tree. 
Awesome!  But I think the .. needs a to be smart about sometimes inserting a /
in front of it.  If I go to http://ftp.mozilla.org/pub/mozilla/nightly/latest
and click on Change Directory Up, I see
Document ftp://ftp.mozilla.org/pub/mozilla/nightly/latest.. loaded successfully
(which is not true, nothing loads)
and most of the time, but not always, I get a slew of assertions:


###!!! ASSERTION: NS_ENSURE_TRUE(edit) failed: 'edit', file nsGlobalWindow.cpp,
line 4988
###!!! Break: at file nsGlobalWindow.cpp, line 4988
An error occurred updating the cmd_cut command
###!!! ASSERTION: NS_ENSURE_TRUE(edit) failed: 'edit', file nsGlobalWindow.cpp,
line 4988
###!!! Break: at file nsGlobalWindow.cpp, line 4988
An error occurred updating the cmd_copy command
###!!! ASSERTION: NS_ENSURE_TRUE(edit) failed: 'edit', file nsGlobalWindow.cpp,
line 4988
###!!! Break: at file nsGlobalWindow.cpp, line 4988
An error occurred updating the cmd_paste command
###!!! ASSERTION: NS_ENSURE_TRUE(edit) failed: 'edit', file nsGlobalWindow.cpp,
line 4988
###!!! Break: at file nsGlobalWindow.cpp, line 4988
An error occurred updating the cmd_selectAll command

(the assertions might not be related).

I haven't applied this yet, but not sure how good a button would be here...?

> function changeDirUp()
> {
> 	window._content.location.href = window._content.location.href + "..";

window isn't necessary.  how about ._content.location.href += ".."; ?

> }

> 	<treerow>
>         	<treecell id="CDup" onclick="changeDirUp();"><button 
id="cdupid" class="button.small" value="Change Directory Up" onclick="alert
('hello'); changeDirUp();" /></treecell>
> 	</treerow>

The button should be using oncommand.  Also, I don't think we need that 
greeting :-)

Why is the event handler on the <treecell/> and the <button/>, instead of just 
the <button/>?
> 


Also, the button value isn't localizable.
oh. the button's onclick wasn't being executed. don't know why, even oncommand
wouldn't work... So I just made the whole treecell clickable. ;P
Also the button's name would need to be localized into a file.
`Change Directory Up' --> `Parent Folder', please. (Well, we *are* showing 
directories as folders in the list ...)

Even Better would be a popup menu (current folder at the top, root folder at the 
bottom) from which you could choose an arbitrary parent directory. Then you 
wouldn't need a string, localizable or not. :-)

"parent dir" or ".." would be more ideal for the button.

in place of a button, though, would it at all be possible to have a pulldown
menu (i.e., like an <option> tag) listing all available parent directories (with
the immediate parent directory as the default value)?  just a thought.

> ------- Additional Comments From ratman@medmail.com 2001-01-18 10:25 -------
>
> "parent dir" or ".." would be more ideal for the button.

".." is a bad idea because apart from UNIX shell users and DOS users I can't
imagine the average person knowing what that means particularly on systems that
don't have a commandline (e.g. Mac). As for calling it a folder or a directory,
I'm all for directories as I prefer correct terminology, however many people are
now used to calling them folders in Windows (what does MacOS call them?) that
using folder may be the more user friendly option.

My guess is that anyone who knows the term "directory" or "dir" will be able to
figure out that "folder" means the same thing; whereas the reverse might not be
true.  So "folder" is probably safer.  "Parent Folder" should be clear to
everybody, right?
And also is needed something like "." to go to main server folder.(e.g. clicking
on it in any folder at ftp.mozilla.org will bting us to ftp.mozilla.org)
1) This is close to slipping off Moz0.8
2) Maybe we could check in the fix and argue over the exact wording later?
3) "." means "Current Working Directory" on both Windows/DOS and Unix. "Root" is
what you mean :)

Perhaps at least set a target milestone :)

Agreed -- we should check it in regardless of what the wording is.  But the
problem of the missing / and the resulting assertions needs to be fixed first.
That sounds like it should be easy, I add some slash-adding cide if Joseph
doesn't have time.
I put together that patch as a proof of concept. It's a rather horrid ui,
someone feel free to fix it up and check it in. I've got bigger fish to fry.
this *mostfreq* bug was initially set for *m12*. what happened?  suggest upping
the priority and setting for moz0.9, since we missed the 0.8 deadline, obviously.

does joseph elwoods's patch need anything beyond localization?  it appears to be
functional enough for the purposes, and i believe the general consensus agrees
with the text "parent folder".  and of course, the little greeting alert would
have to be taken out, unfortunately.

my cvs is severely maligned - can somebody make an official proposed patch for
at least this one issue (in order to deal with other directory issues in other
bugs)?

please...
Assignee: law → akkana
Status: ASSIGNED → NEW
Component: Networking → Networking: FTP
Keywords: mozilla0.8 → mozilla0.9
Don't forget that it needs an extra slash.  But with that added, I'd sure love
to see this get checked in.  It doesn't matter what the button says, we can
always change that later.

I dunno how or when this got reassigned to me.  But okay, I'll add the slash and
request r and sr.
Status: NEW → ASSIGNED
Oh, I guess I count as the reviewer, since the patch is really Joseph's.
mscott is listed as the sr person for netwerk; Scott, can you please review this?

The added slash will sometimes result in a double slash, but that's legal.  If
you think it's a problem, I can add more JS to only add the slash if there isn't
one there already ...
Keywords: patch
Whiteboard: needs sr
Target Milestone: --- → mozilla0.9
> window._content.location.href = window._content.location.href + "/..";

Simplify this to |.content_location.href += "/..";|?

>  <button id="cdupid" class="button.small" value="Change Directory Up"
> onclick="alert('hello'); changeDirUp();" />

Please use onclick, not oncommand, remove the alert(), and don't forget to 
localize this value...


> Please use onclick, not oncommand

Er, the other way around, of course (use oncommand, not onclick).
OT: will this patch also fix the dreaded "can't activate ftp-site from sidebar
-> bookmarks since when clicked, ftp will try to show file list in sidebar and
not in main view" bug?
perhaps window._content.location.href.replace(/\/*$/,"/..")

yes i do mean * and not +.
I agree with Blake's and Timeless' comments, and have attached a patch with
their changes.  I haven't tested the new patch, however, because ftp is entirely
dead in yesterday's build (will test if I ever manage to get a working build
that includes ftp).  We're still looking for an sr (mscott?)
Thanks, but we still need to localize `Change Directory Up'
What happens when you can't go up any further? (ftp://foo.com/, gopher urls,
file:///)

Peter Lairo: Thats a feature, not a bug :) Although it doesn't work from the
bookmarks menu at the moment for some reason. Also see bug 36224.
I don't know what happens if you say ftp://ftp.site.com/..  Probably nothing
useful.  Though personally, I'd prefer that to the current situation of not
having any way (short of editing the urlbar) to go up.

I can't test it (or anything else in this bug) because ftp has been broken for
me for a week -- bug 70258.  Marking dependency.  I hear ftp actually works for
some people, maybe they can test this.
Depends on: 70258
TestProtocols shows ftp giving the same directory you had originally, with a uri
not including the .. - the server strips the ..'s, I think. file works properly,
and gopher doesn't - .. is a valid part of a gopher path.

.. on a mac will open a file called .., according to BHart, which means that
this is definately a bug.

Note that I haven't applied the patch, because of all my local changes.

Its confusing ("Clicking on this button does nothing - it must be broken"), and
wrong. The correct fix is probably to just strip off everything up to the last /
(special casing if the last char is a /), and not displaying the button as all
if we're at the top level. Pinkerton says that file://foo:bar:baz encodes the :
to %3A, but opens the file regardless, so thats not a solution for the mac.

As well, I think adding a / after the .. may mean one less connection to the
server (for ftp). I'll test this later this week.
Bug 64795 may be of interest to people on this bug, and may ultimately be enough
of a fix (certainly a workaround): it gives a patch and a pref to make ftp
return simple html (like 4.x) rather than the current directory listing. 
Unfortunately, the current patch is broken.
Bug 64795 would be a great temporary workaround to this bug (it doesn't fix the
lack of an "up" button in the directory viewer, but it lets people choose the
old-style html output and not use the directory viewer at all) except that it
also omits the parent.  DougT said it would be easy to add a ".." entry, though.
Assigning to him for the workaround; when that's in, he'll reassign the bug to
whoever owns the coming directory viewer rewrite.  Thanks for the workaround, Doug!
Assignee: akkana → dougt
Status: ASSIGNED → NEW
Assigning to xpapps manager.
Assignee: dougt → pchen
could this pls be reviewed/tested and checked in soon? ie, assuming it's okay
and hasn't bit-rotted... unless the workaround akkana mentioned would be better?
Keywords: review
suggest keyword: *nsCatFood*
I'm using the workaround; DougT checked in the code to enable ".." when using
the old-style html display instead of the xul directory viewer.  The ".." is
small and it's hard to tell what it is (since the dots are very close together
and also underlined since it's a link), but at least it's there.

Of course, no one will discover this, so it would be nice if someone could adapt
the last version of the patch to do whatever dougt's workaround code is doing,
so we could check it in.  I could do it if I got some free time, but that's not
going to happen this week and probably not next week either, so help would be
appreciated.
how is the old style html enabled? and a pointer to dougt's new code (either a
bug, patch, or lxr) would help.
jelwell: see bug 64795.
[note to self: the backend pref for the workaround is
("network.dir.generate_html", true)]
Moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
nav triage: Paul, we'll move this out to mozilla0.9.2 since its not critical for 
beta. also this is not a nsCatFood+.
Keywords: nsCatFood → nsCatFood-
Target Milestone: mozilla0.9.1 → mozilla0.9.2
We now default to the html view of ftp sites.  This means that for the default
there is a ".." to get up a level.  

note: This bug is NOT fixed or worksforme.
doug, can you make the ".." into "Up to higher level directory" when in ftp?
Assignee: pchen → dougt
Blocks: 81552
future.
Target Milestone: mozilla0.9.2 → Future
*** Bug 86813 has been marked as a duplicate of this bug. ***
*** Bug 91143 has been marked as a duplicate of this bug. ***
> *** Bug 91143 has been marked as a duplicate of this bug. ***

Bug 91143 "file URLs for a directory does not display link to parent"

is specific to file URLs.  This bug is summarized for ftp URLs.  Here is what
I see:
 - http URLs work and display "Parent Directory" links
 - ftp URLs sorta work and display ".." links
 - file URLS display no links to the parent directory
Bob, http is not in the same set as ftp and file.  Http gets *ALL* of its
content from the server.  Directory listings, file not found, ect., all come
from the http server.

File uses the directory widget.  Blake's and Timeless can check in their patch
if they like and it is okay with bbaetz. {if (r==bbaetz) sr=dougt}.

For Ftp, we generate our own html.  It uses the string ".." cause we hit the
l10n deadline.  Feel free to write up a bug about this string, if there is not
already...

note Judson Valeski's comment from way back in 1999-12-18

> don, waterson currently owns the directory listing code which file and ftp urls

back in the day when this bug was filed, ftp was using the same directory
listing code as file. At some point since then-- I have no idea when, that was
changed. ftp:// no longer uses the same code as file:/// it now uses generated
html, as dougt just pointed out.

This bug should probably be marked invalid because the symptom it originally
describe is ancient history. Any issuses with the .. in the generated html for
ftp listings should be (and might already be) handled in a separate bug.
I don't read regexps well, but that looks reasonable, so r=bbaetz if

- it works
  - its tested on mac
  - its tested and works on mac with a directory with / in the name
- its disabled for gopher
- you localise the "Change directory up" text
- we don't do horrible things going up from file:///C|/, ftp://ftp.mozilla.org/, etc
- you remove the uneeded id attributes from the button/treecell
Oh, and while this code no longer handles ftp by default, it does handle file still.

So the ftp tests above should be done with the xul directory viewer, not the
html one (the pref is in the debug pref pane)
MozillaUser@HamsterRepublic.com: the main reason FTP was switched to HTML view
was because of a few issues with the XUL directory viewer (this being one of
them), HTML view was originally devised for embedded apps that don't want to
include XUL support, so XUL view will probably become the default again in the
future, but HTML view probably always be an option.
The default pref has changed, but nobody has suggested that we could abandon the
"tree" widget at this time, so we need to track ths.
see bug 69185: implement outliner in ftp and file [directory] listings.
qa to me.
keyword -> 0.9.4 now.
Keywords: mozilla0.9 → mozilla0.9.4
QA Contact: tever → benc
See also bug 33684, an rfe for an "Up" navigation button that could be used at 
any page to chop off the last part of the URL.
Assignee: dougt → bbaetz
reassigning to bbaetz@cs.mcgill.ca.
Dir viewer stuff, so ->xpapps, and ->0.9.6 for dirviewer cleanup targetting.
Component: Networking: FTP → XP Apps
Target Milestone: Future → mozilla0.9.6
bbaetz: could you not fix this bug, at least for when the links toolbar is
enabled by default, by adding <link rel="up" href="ftp://foo.com/bar/"> to the
generated HTML? Obvious <link>s you could use are Top, Up, Previous.

Gerv
dirviewer rewrite, -> 0.9.7
Summary: ftp and directory listings can't go to higher level directories → [xul] directory listings can't go to higher level directories
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Given the <tree>-><listbox> changes, which mean that <tree> will become
<outliner> automatically (and my current time constraints), I'm going to push
this off for the moment. 0.9.8 is out for me, so that means 0.9.9

The bugs being changed this way either require <outliner> support, or would be a
lot easier with such support
Target Milestone: mozilla0.9.7 → mozilla0.9.9
OK, moving all XUL dirviewer bugs to post 1.0. I don't want to be doing this,
but there are only so many hours in the day. These will be taken earlier if
someone submits a patch, or I find time.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Following the roadmap, 1.0.1 is a maintenance release, so pushing off features
(xul direviewer) to 1.1
Target Milestone: mozilla1.0.1 → mozilla1.1
Keywords: mozilla1.1
I just switched to XUL based directory display again for testing and it seems to
be very stable, integrating the patches would finally render XUL based directory
listings usable
adding keyword mozilla1.1
*** Bug 141155 has been marked as a duplicate of this bug. ***
xul dirviewer bugs -> 1.2. I have no time..
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Whiteboard: needs sr → [xul dirviewer]
Target Milestone: mozilla1.2alpha → mozilla1.1alpha
*** Bug 143969 has been marked as a duplicate of this bug. ***
QA Contact: benc → sairuh
*** Bug 157087 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 33684 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: