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.

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.

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

bulldozer to M12

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.

I think this is a newlib bug. valeski?

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.

who the hell is donm

setting shrir as qa

changed summary from "file:// URL's - can't go to higher level directories"

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

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

Reassigning for Don

Move to M21 target milestone.

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

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

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?

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://

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

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

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

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.

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

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

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!

Assigning to xpapps manager.

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?

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

nav triage: Paul, we'll move this out to mozilla0.9.2 since its not critical for beta. also this is not a nsCatFood+.

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?

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.

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.

reassigning to bbaetz@cs.mcgill.ca.

Dir viewer stuff, so ->xpapps, and ->0.9.6 for dirviewer cleanup targetting.

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

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

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.

Following the roadmap, 1.0.1 is a maintenance release, so pushing off features (xul direviewer) to 1.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..

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

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

*** This bug has been marked as a duplicate of 33684 ***

marking verified as a duplicate. if you decide to reopen this bug, please clarify why. search string for bugspam removal: SalviaGuaranitica