Heres an idea I think would be really freakin handy. Every browser since the stone age has had back and forward navigation, but theres another movement thats common, and could be automated..."up". Say your at... metalab.unc.edu/foo/bar/baz.html *click up* metalab.unc.edu/foo/bar/ *click up* metalab.unc.edu/foo/ *click up* metalab.unc.edu/ *click up* unc.edu/ Moving one up in the directory tree is a common task, and to: - go the address line - highlight the current file/directory - delete it - hit enter is a pain, when it could easily be automated.

So #mozilla tells me MacOS IE5 already does this. Now Microsoft is stealing my ideas before I even think of them. Bah. Hydra points out similarities to domain/hierarchical navigation in bug 21521 although that deals only with history, where "up" can take you to pages you haven't yet been. Might be possible to implement them together though.

I thought of this a while ago, but then changed my mind. The reason is that while some sites have a nice hierarchy determined by slashes (Yahoo-style), most sites actually don't. So clicking the Up button would result in 404 or 403 errors a lot of the time. Perhaps word selection using slashes in the location bar would solve your problem -- so you could stick the cursor at the end of the URL, and then press Ctrl+Backspace to delete up to the previous / character?

Uhm...seeing as all web servers I know of serve hierachical file systems, this wouldn't generate any 404s. You eaither get the default page (index.php3, default.htm, what have you), or you get a listing, but not a 404. trying to make it quicker to delete part of an URL to accomplish Up navigation is a mistake: - what if there are word-break type characters in the file name, you'll have to delete twice - you still have to click on the url, let go of the mouse, type stuff, hit enter, pick up the mouse again, instead of clicking "Up" I'm not looking for Yahoo-style neatness here, just to see what's up a little further. If i follow a link in to isp.org/joebob/pictures.html, he might not have a link to his main page, since i might have gotten pictures.html from a search engine or something, and it might supposed to be in a frameset. I click up, and it goes to /joebob/, and i get his main page. Then if he has an interesting domain, and im curious, i click up again and check that out. I do this daily, manually, so I must *insist* someone starts coding an up button *now* =)

This is really only valid for FTP as a concept. Many webservers do not permit virtual directory listings, and so you would get errors going up them. Even if you did, the page might not be at all relevant. What about generated pages in cgi-bin directories? Imagine the amount of newbie confusion this would cause - "this button doesn't work - it takes me to broken pages". It also clutters the UI. Most web designers provide an "up" if you need one, in the same way that they provide other navigation. "- what if there are word-break type characters in the file name, you'll have to delete twice" - not if your way of deciding how far to move was vaguely intelligent. " - you still have to click on the url, let go of the mouse, type stuff, hit enter, pick up the mouse again, instead of clicking "Up" " - or you could use (when the hotkeys are implemented) Ctrl+Shift+Tab (Go to URL bar), left arrow, shift+right arrow, space, enter. Gerv

Ah the newbies. More interface dumbing down so as not to confuse the newbies. I can see your point, however I think *easily* more then half of the time, it wouldn't take you to a broken page (right now, it would take me to bugzilla.mozilla.org's main page...not a 404...and clicking up again takes me to we're 1 for 1). Most of the time there is something the next level up. If its not in the default chrome, can a 'hook' be added, so other interfaces can implement the button? This is a feature I would really really make use of, in http://, file://, *and* ftp://. Anyone out there feel this is a huge browsing advancement, or am I all alone here?

How about we send this to UI Design Feedback for discussion. Then if someone agrees to impliment it and has a patch we can see what happens.(It was done last fall, I think. Check n.p.m.ui or n.p.m.xpfe for the discussion and maybe even then necessary XUL and javascript).

I have no opinion, and defer to Brendan.

While I can see the value of this feature in a small subset of cases, I think a large part of the time, it is not a useful feature and yes, will lead to broken pages. 50% is not the margin we're looking for here, either. Even if greater than half the time it works, that could leave up to 49% failure. It's also not a case of "dumbing down for newbies." Rather, it's a case of NOT "cluttering up for power users." There are a lot of features we could add that are useful to the 2% of users that need them, but for the other 98%, it's just in the way. In a case like this, it's in the way for most users AND it has a fairly high likelyhood of failure. Therefore, if it exists, it cannot be prominently displayed (such as in the toolbar). Oh, and if Mac IE5 has this feature, I can't find it. The closest they come is displaying the pathname as links in an FTP directory. I have to agree with Gervase that this is only *really* useful for FTP. Though all web servers are reading files from a heirarchal file system, fewer and fewer of them are actually using that to define their sites. Therefore, I recommend that this not be implemented as a web browsing feature; some form of it would be useful in directory listings.

Resolving/verifying as WONTFIX per brendan's comments. Jeremy, please feel free to re-open this bug, assign it to nobody@mozilla.org, and mark it with a helpwanted keyword, in case a mozilla contributor would like to implement it for Mozilla.

Verifying as WONTFIX. (Yeah, Matthew...)

Is it possible to add a hook for it, and just not a button in the default chrome? Mac IE5 does it, I'm told, by Option-Clicking the URL.

Yes, it is possible for you or a Mozilla contributor to check out the code through CVS and personally implement a hook for this feature, if the module owner approves your (or the code contributor's) idea and implementation. (I'm not sure who it would be offhand.)

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

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

Actually, Mac IE5 also does this when you command click the title of the window in the title bar... This is actually an implementation of 'Standard' behaviour on the Mac - the Finder does this for local folders, command click the name of a folder in the title bar and you see all the enclosing folders on disk. BBedit and CodeWarrior implements this too - its becomming more common. IE5 does it for URLs on the remote web site. The nice thing about this implementation is its newbie proof, because its hidden - only people who are conversant in the Mac UI would look for it. Whether its sufficently useful that it should be more obvious how to do it is debatable. I think Apple are making it more obvious in Mac OS X

On a different topic, I'd like to point people to bug number: http://bugzilla.mozilla.org/show_bug.cgi?id=2800 Support for HTML 2.0 <link> tags. I think these would be an extremely good way to implement an 'UP' button as they would allow the page *author* to specify how the 'Up button' would function.

well thats all nice and good, as long as we can convince the million web designers out there to immediatly add a HTML 2.0 <link> tag to all their pages. convince them, and ill transfer my vote to 2800.

It seems like this bug was marked WONTFIX based on the idea that such a button doesn't belong in a toolbar. If bug 2800 replicates all of their functions in the GO menu (As I just requested) We might be able to use that "up" command to truncate the URL to go "up" a directory. If the page has a "link parent" then the Up menu command will do that, if the page does not, then the up menu command will do what this bug proposes. Since no one really looks in the go window, newbies won't even want to click on the option and it wont cause a problem. I think this bug/RFE needs to be reopened and rediscussed.

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

From bug 89005 a possible solution: ------- Additional Comments From Simon Montagu 2001-07-03 03:00 ------- This is very easy to achieve manually by adding the following bookmark to the Personal Toolbar Folder: javascript:void(location.href=location.href.substring(0,location.href.substring(0,location.href.length-1).lastIndexOf('/')+1)) --Steve Kangas at bookmarklets.com This doesn't solve the foo.bar.com -> www.bar.com problem however. Perhaps a bit more javascript...

While it's true that this can lead to invalid URLs, it's also a very useful way to get *out* of invalid URLs by working up the directory structure until you find something that works, and if you're lucky a link to what you were looking for. It can also create infinite loops because of redirection, but so can the Back button and I don't see anybody suggesting that we don't need a Back button so as not to confuse the newbies.

Jeremy, as per Eli Goldberg's comment from 2000-03-29 14:12, can't you re-open this bug, assign it to nobody@mozilla.org and mark it with the helpwanted keyword? After all, there are three duplicates and one vote for this. And in a minute (after I add mine) you'll have two :-). Thanks!

This bug should have the word "button" in the short description to make it easier for people to find it (so they can vote for this one instead of filing dups like I did (bug 89005)). If somebody authorized could add it, that would be great!

Due to continued interest in this bug, I am opening and assigning to nobody@mozilla.org. Adding helpwanted keyword. If the bookmarklet above works well, I'd advise perhaps adding a "up" function to the go menu with that code. (is Alt-upArrow being used as a shortcut?) If the "LINK" bug 2800 gets fixed and the code is added to the Go menu, then the proper "up" action can substitute for truncating the URL. Adding "button" to summary per Johan's comments

reassigning because you cant reopen and reassign at the same time. (Sorry for the spam)

It would be nice for the "up" action to repeat if an HTTP error was encountered...

The Go/Up looks fairly simple. I need to investigate en/disabling though. Note that the Alt+Up keystroke doesn't work if the URL bar has the focus.

In response to neil@parkwaycc.co.uk, I don't think repeating on HTTP errors is a good idea. The repetition is either fast, and in that case I'd think the button was broken (since it moved up two steps even though I only clicked it once). Or it's slow (if the server is slow to respond), and then I wouldn't win anything (because I can just as well click it once more myself). Also, if the top page is not available (weird but very possible), you'd get an HTTP error either way. I don't know what others think, but I don't think it's a good idea. YMMV though.

it's an interesting idea. i'm not sure whether i'd want up to go up on failure. has anyone here tried google's ie plugin? it has an up button, actually an up dropdown list...

it certainly shouldn't go up on failure, because certain sites now redirect on failure (try the free website services) Since they take you somewhaere completly different (sometimes to a different server) going up again would just cause problems. About the patch. Shouldn't we use location.pathname instead of location.href ? I know you use a Regex to make sure we don't overwrite the host, but if we're just truncating the path anyway, can't we get the pathname, truncate it, and concatenate it back onto (location.)protocol+hostname ? (now that I look at it it will probably be more work... but I'll throw it out there anyway) Also, this patch will implement the 1st part of Go/up. It will truncate the Path down to the hostname. i.e. http://bugzilla.mozilla.org/foo/bar/ will become http://bugzilla.mozilla.org/foo/ However, we still have the issue of the host. I say we go ahead with the patch we have and then work on the second part of this bug. The problem I see in the hostname part is that there can be alot of things in with the hostname itself. http://user@foo.bar.mozilla.org:80/ is a valid URL (I think) what exactly would be "up" in such a situation? I'd say get rid of the port, then the username and the first subdomain(is that what they're called?) (foo), then the next (bar) leaving eventually http://mozilla.org/ But I'm sure others would disagree... adding patch keyword...

Per a conversation with timeless on IRC, I am reassigning this bug to myself and sending it to the proper component, XP Apps: GUI Features. Adding review keyword, and pinging ben@netscape.com to get the review process underway. Neil, since you wrote up this patch, I'd like to to own this bug, but I did't know whether you wanted it and didn't want to spam the default owners at XP Apps, so I took it. feel free to take it.

.

I haven't tried the patch, but one thing to test is hitting Up twice on a slow server. It should go up two levels, just like hitting Back twice goes back two pages. (Note that you'll have to use the mouse to test, since bug 81951 prevents keyboard shortcuts from working while a page loads.)

I've been running with this patch for a few days now, and It seems to work fine. It will not however go up two levels if you press it twice quickly. The reason is that it gets the location of the page you are viewing and just truncates the href string. While it loads a new page, the "location.href" attribute remains the same. You don't get a new location value until the server is contacted successfully and downloading begins. So hitting up multiple times before the connection gets made will just keep trying to load the same page. Hitting up after the connection is made and the location changes will result in going up two levels. example: Up, Up, Up, Up will just produce the result LoadURI(foo/bar), LoadURI(foo/bar), LoadURI(foo/bar), LoadURI(foo/bar) Up, pause, Up, pause will produce LoadURI(foo/bar), LoadURI(foo) I'm not sure how we could achieve a different result unless we added alot more code. Also, one nitpick with the patch, the Shortcut key in the menu should read "Alt+Up Arrow" instead of "Alt+Up" Reassigning to neil, and removing blake as QA because he wanted me to keep the spam away. :-)

Mike Young wrote: > It will not however go up two levels if you press it twice quickly. I'm not > sure how we could achieve a different result unless we added alot more code. I did look at this but I couldn't figure out when to update the command :-( > Also, one nitpick with the patch, the Shortcut key in the menu should read > "Alt+Up Arrow" instead of "Alt+Up" That's an i18n fault but if you file a bug against me I'll give you a patch.

Up-Down bug is 90774 The only way I could see to make us go up more than one level at a time would be to get the URI from somewhere other than location.href Unlike back and forward we don't have a list to run off of, we dynamically create the new URI. Anyone know of a way to get the URI of the page *being* loaded? If we could get that we'd just have to check if a load was in progress and get the URI from whichever source was relevant.

IE uses Alt+Up to open drop-down select boxes. We could work around that by only supporting Alt+Down for select boxes, using a different key to navigate up, or making Alt+Up to navigate up work everywhere except on select boxes. (See also bug 33684.)

This is bug 33684... maybe you meant another? I also was thinking how to avoid the shortcut key conflict. Alt-Up Arrow really should be the shortcut key since alt-left and right are back and forward. It'll just be more logical. (Not that shortcut keys are ever logical) Personally, I think that since dropdown boxes are by very definition drop-*down*, alt-up shouldn't even apply. but I think that we should cater to converts from IEism so the idea of having alt up work everywhere but select boxes seems OK to me. (I'm just waiting for the argument that shorcuts shouldn't have different effects in different places)

Sorry, I meant to link to bug 57192.

Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.

scary: + if (upDisabled != !_content.location.href.replace(/#.*$/, "").replace(/?.*$/, "").match(/\/[^\/]+\/./)) i think the replaces can be improved based on this example: javascript:"http://www.mozilla.org/foo.cgi?string=bar#baz".split(/[#\?]/)[0] i'm still thinking about match and the whole != ! and match() bits.. we mentioned that there's an nsiurl and js has some url object so this patch is unlikely to be final, but it's still something to talk about

From discussion on IRC. The question arose whether the script handles frames properly. if we use document.url vs. window.location, we have to check out our handling of frames. From what I can tell, the patch here will go up one level from the *frameset* which is probably the easiest way. (we really dont want to have to worry about the individual frames) Just thought I'd mention it.

Is this bug just going to stagnate further?

See also bug 12707, nothing to click on at local directory listings to go up a directory.

Not sure what the implementation idea is, but two points: UI isn't critical. Since it's an advanced user action, alt+Up should be enough If there is UI, default it to off, since it will generate 404s on those lame webservers that use wierd tree structures and don't list directories. *cough*iPlanet*cough*IIS*cough*

I would very much like to see an up *button*. Since you are the original reporter, you know better than I do what you are after, but if this bug is resolved without an up *button* being added, bug 89005 is not a duplicate of this one and should be reopened.

The included patch adds a menu-item (or "button") to the go menu where back and forward are. The patch essentially chops off everything at the end of the URL to the last forward slash. The button is deactivated if there is nowhere to go. Alt-Up is the shortcut key sequence to use instead of clicking on the choice in the menu. Hope that helps! On another note, do we need to escape all the backslashes in the RegExp? It makes it terribly confusing to decipher. I thought we didn't need to do that in JS.

It's the /s that need to be escaped with \s. In Perl you could use s|/[^/]*.$|/| instead.

You can call RegExp("/[^/]*.$") (with or without operator new) also, but you should do that outside of any loop (the literal notation gets hoisted by the JS compiler). /be

from bug 87428..... ------- Additional Comments From Johnny Stenback 2001-10-01 08:13 ------- One can also use var ifrq = window.QueryInterface(Components.interfaces.nsIInterfaceRequestor); var uri = ifrq.getInterface(Components.interfaces.nsIWebNavication).currentURI; to get at the current URI if you have full XPConnect priveleges. This is not 100% bullet proof either, but it's less likely to be wrong than using location.href ---------------------------------- Over in that bug they were also having problems with using _content.location.href This is their solution. It is considered "safer". Navication should probably be Navigation, but I left it how he wrote it. This might also have an effect on the "click twice in succession should take us up more than one level" issue we were discussing on 7/11/2001 Although I'm not sure. If this method works, could we have reviews of the patch? Its been sitting stagnant for a while now.

There are some comments on bug 61886 in navigator.js which is why I didn't do it that way. But anyway, you don't need all that code, just replace _content.location.href with webNavigation.currentURI.spec in UpdateBackForwardButtons() and getWebNavigation().currentURI.spec in BrowserUp().

See also bug 102909, "No keyboard access to link toolbar".

blake: This bug keeps getting pushed back milestones while a perfectly usuable patch sits here bitrotting. We have requested reviews and as such nothing has happened. Please provide us with some reason as to why this can/cannot go in. It is a very simple, very un-risky patch and I can't see why it keeps getting postponed.

The links toolbar wasn't held up for bug 61886, so this bug shouldn't be held up for it either.

blake, You pushed this back again.... Is there a reason? It would be very nice to get this in. it is a trivial patch that implements a very useful feature. If you could provide a reason it would be greatly appreciated

Reassigning to Neil, since he's working on it. Note that I fully expect (and hope) that the current patch will fail sr=, since it clutters the `Go' menu with a nearly useless item.

mpt, where would you put the menu item, if not in the Go menu? It's hard to "clutter" the go menu, because it exists primarily to allow keyboard access to navigation toolbar buttons let users find the keyboard shortcuts for those buttons. I manually chop off the ends of URLs very frequently, almost as frequently as I use session history or the home button, so I don't see how this feature could be "nearly useless".

jruderman, anyone: I use the Go menu frequently to go-back-N and occasionally to go-forward-N where N > 1. I've done so for what, seven years now? Am I alone? The Go menu in the browser (not in mailnews) is certainly not just a throwaway tool for teaching users keyboard shortcuts. /be

ummmm. exactly how can we be "cluttering" up a menu with only three items? I think that it is just making the Go menu "more complete". I use Up navigation (by hand mostly) all of the time, and I think that it would be a very useful feature. If we implement it at all, it should definately be placed with the other navigation commands (back forward home) it is the only logical place for it to go. Now if we want to talk about clutter, look at the file menu.....

Status? Does the latest patch include a button, with a dropdown to go up a few levels? It should of course default to off, as should all of the other completly useless buttons (excuse this quick rant). Bookmarks: already have a menu AND a tab on by default Go: uhm... 'enter'? Why do I want to switch to the mouse. Home: just another bookmark, but my home is about:blank, so, whatever Search: URL dropdown. If I'm typing why would I switch to the mouse!? Print: er...alt-f,p and ctrl-p too hard? Did I mention I don't own a printer? That said, it is a power feature and will occasionally generate errors on lame servers, so it should be off by default. To back up what Jesse said... I manually go Up much more often then I use the forward button, and probably almost as much as I use back. As for mpt's concerns about the Go menu, if the toolbar button isn't enabled, can the menu entry be disabled as well? Can this make 0.9.6?

Adding a button is bug 89005, which is blocked by this bug and by the lack of customizable toolbars.

This is not a priority, and I don't see why it has to involve a toolbar button at first -- why not give those who want it a Go menu entry with a keyboard shortcut? Timeless asked me to plunk for this feature, but I'm leery of it growing into a big all-or-nothing distraction from mozilla1.0. We have lots of other bugs and features to work on that I think have higher priority. If this is to be done, 'twere better it be done quickly! /be

> I don't see why it has to involve a toolbar button at first The browser already comes with a bookmarks (useless), go (useless), home (useless), search (useless), and print (useless) toolbar buttons ON by default. There certainly can't be any futher harm having an Up button which would be OFF by default. If it's only a keyboard shortcut, you mine as well just backspace on the URL a bit. The point of having a button is you avoid switching to the keyboard then back to the mouse. Especially CTRL+Up, which is a right hand combo.

jmd: there is currently no fast way to go "up" with either the mouse *or* the keyboard (or even a combination of the two). Adding a keyboard shortcut would not be pointless, even for users who prefer to use the mouse for most tasks. If you want a button, go vote for bug 89005 instead of whining here and contributing to bitrot.

Updated patch in the off-chance that it will make 0.9.7 :-)

Neil, Why does the diff have cruft from navigatorOverlay.xul? It looks like the diff caught an unnecessary change. Hopefully we can get reviews of this patch... and here are the reasons why... 1. This is a simple (no overhead) script level patch. 2. It adds one (very useful) item to the go menu (which is currently 3 items long) 3. It provides us with a starting point for hierarchial navigation of FTP and file directories. (Which is currently lacking) 4. People download add-ons to browsers to implement this (simple) feature. (The google toolbar, bookmarklets, etc.) 5. The keyboard sortcut is logical and intuitive. (When we are in a list box we match IE by opening the list... This is stupid, but oh well...)

Comment on attachment 60813 [details] [diff] [review] Patch to fix bitrot Index: communicator/resources/locale/en-US/contentAreaCommands.dtd ok. >Index: browser/resources/content/navigator.js >=================================================================== >RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigator.js,v >retrieving revision 1.412 >diff -u -r1.412 navigator.js >--- browser/resources/content/navigator.js 2001/12/06 09:35:37 1.412 >+++ browser/resources/content/navigator.js 2001/12/07 17:25:24 >@@ -187,6 +187,7 @@ block ok. getWebNavigation().currentURI.spec.replace(/[#?].*$/, "").replace(/\/[^\/]*.$/, "/")); I still don't like this form. I need to think about it, or find a js eng perf aware person. >Index: browser/resources/content/navigatorOverlay.xul this file is from some other patch :-( remove it. we'll have to talk w/ aaronl about these bits. it's ok w/ me. we are of course aware that it will only work for document contents, which makes sense to me. >Index: browser/resources/content/unix/platformNavigationBindings.xul >Index: browser/resources/content/mac/platformNavigationBindings.xul >Index: browser/resources/content/win/platformNavigationBindings.xul >@@ -8,6 +8,7 @@ >+ <key id="goUpKb" keycode="VK_UP" command="Browser:Up" modifiers="alt"/> warning: >cvs server: browser/resources/content/os2/platformNavigationBindings.xul is a new entry, no comparison available you can do diff -N to get the contents of this file, but since i didn't see any build changes (jar.mn) i don't see the point in this being here...

Comment on attachment 60966 [details] Adjusted testcase for root directory Sorry, it's wrong again. Forgot another obvious test. New attachment in one moment.

This testcase checks for "http://www.foo.pv?bar" and returns "http://www.foo.pv". The second testcase, marked obsolete, returns "http://www.foo.pv?bar". I don't know which is correct in this instance.

Replace if (url == "http:/") { with if (url.length == url.indexOf("/") + 1) { Forgot about non-http:// protocols, such as file://

This patch includes the correct navigatorOverlay.xul diff. The os2 file had been cvs removed, thanks for pointing that out. The point of the two regexps is to remove any anchor or query, then to remove the tail of the path, leaving just the last directory. Note that the trailing / is not removed, because the server will only redirect it back. I'm also not checking for http://www.foo.pv?bar because it's not a valid URL.

Sorry about the SPAM, but I forgot to use cvs update -A :-(

> mpt, where would you put the menu item, if not in the Go menu? I wouldn't put it anywhere, since it would (in my opinion) be more confusing and annoying than useful -- there's a *reason* why it's only available in add-ons, not in the default UI for any major browser. (IE/Mac's UI for it is so well-hidden, you can't find it without someone telling you it's there.) And trying to excuse its introduction by comparing it with other bits of confusing and annoying crap in Mozilla (the current toolbar structure and the `File' menu) really isn't very impressive. Two wrongs don't make a right, etc. I think commensurate effort for such a function is to perform the following sequence of keypresses: 1. Ctrl+L (Command+L on Mac) 2. Ctrl+Backspace (Option+Backspace on Mac) 3. Enter. That sequence doesn't work now, but it should.

I personally would like such a button -- but I'm a poweruser. It seems to me that this is an excellent candidate for a button not on any toolbar by default but able to be added to toolbars when toolbars become customisable (pending bug 15144). End users never bother to customise anything, so they'll never see it; power users can have it if they want, with the caveat that it might sometimes produce 404s (or, more likely, "Forbidden" pages) when the server is misconfigured. I would also note, most of the sites where it would fail are either commercial or trend-oriented, the kind of site that won't work without Javascript enabled, require flash, and break for a few days every time someone finds a new security gap in IIS. In short, end-user sites. Most useful, information-oriented sites are still organised heirarchically. I realise the former kind of site are more popular in general, but the latter kind are more more frequented by certain subsets of the browsing populace, especially power users, and for those kinds of users (such as myself), the success rate for URL trimming is over 90% -- when I trim URLs, I almost always get a valid page. So, I would consider this feature a valuable convenience. It isn't urgent; there are obvious and simple workarounds. But I think it does have value. However, I'm thinking the target milestone may be just a tad optimistic.

I've been using the bookmarklet for the last month and am pretty much satisfied with it. You can't go up two levels quickly, and you need the PT enabled (which I was already using), but other then that, it works like a champ. If you want to try it, add a Personal Toolbar bookmark, named '..' or 'Up'. Set the location to: javascript:location.href=location.href.substring(0,location.href.substring(0,location.href.length-1).lastIndexOf('/')+1)

I'm another "power user" who would like to see this feature... I do on occasion try to navigate by "slicing off" the URL. This does, however, often result in a failure (especially in poorly designed sites that don't make logical use of the hierarchical directory structure and/or don't use default index files intelligently), and it's also easily confusable with the true "Up" button that's present when LINK elements are used and the link bar is enabled, so I see this as definitely a "power user" feature that should be hidden away sufficiently as not to confuse the "newbies". But I'd still like to see Mozilla have such features. Maybe there should be a configuration switch somewhere to go between "Newbie Mode" and "Power User Mode", with the installation default set to newbie mode, where any dumbing-down deemed necessary so as to keep from confusing the masses is applied in the newbie mode but removed in the power user mode, and various powerful and useful, but possibly confusing and/or dangerous, features are turned on in the power mode.

This should create a link that you can use to download an add-on (assuming you enable it) to create the Go/Up menuitem. Unfortunately I can't overlay the item directly becuase the Go menu doesn't have an id :-( so it's a bit of a bodge...

jag, is there any mileage in adding ids to all the top level menus and popups?

I'd be ok with having Alt+up but no menu item, and I think most power users would be too. Having the keyboard shortcut would probably be enough to encourage web site designers to think about how to make their site structure work with an automated up command, either by adding <link> tags or by arranging the site hierarchically.

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

Neil package still works in Mozilla 1.1a+ 2002071008 (almost 1.1b) on MacOS 9. It has been a lifesaver for me. I know that a lot of sites aren't really navigatable with this command (like cnn.com), but I hope that they'll start using it more when they see the menu-item. Nobody 'sees' a hidden keyboard shortcut. A Flemish newspaper-site already changed their directory structure when I explained that us geeks are cutting the last part of the URL to find back the 'parent' URL to a story (which would be the main page of that day, or the main page for a specific section). Well, I got drunk with their webdesigner in a bar a while ago, so ... She didn't understand why they got lots of weird HTTP-requests on their webserver (must be all those hundreds of millions of Mac-IE5 users, heh), so I explained it to her.

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

I noticed that Phoenix has a <menupopup id="goPopup"> - any chance of this getting into Mozilla?

The new patch is crashing Mozilla {Build ID: 2003011708}.

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

Jesse: A few things I'd like to comment on... First of all, not everyone is a power user and Mozilla should not be tailored to power users, but to all users. Second, why should the browser push web designers into a hierarchial site structure? Some sites don't work like that. Although, I do think an up button is needed. Also, there _is_ an UP button, but it needs to be work in directory listings.

The googlebar adds this functionality to another major web browser (see the "Up" button help at http://toolbar.google.com/button_help.html) and I find it useful. I'm also a power-user, so I don't freak out if the results of clicking "Up" don't get me a valid page. Also, the googlebar is more than just a button... like mozilla's "back" button, it has a menu that gives more options. For example, if I'm on the URL http://mozilla.org/catalog/end-user/customizing/, the menu provides the following options: http://mozilla.org/catalog/end-user/ http://mozilla.org/catalog/ http://mozilla.org/ The options for a page such as this (http://bugzilla.mozilla.org/show_bug.cgi?id=33684) would also include an option to go to http://www.mozilla.org. So, yes. It's not a tool that every user would use, but it's very powerful for power users. Add an option to the "Advanced" settings to turn it on or off.

Thanks to neil@parkwaycc.co.uk for attachment 103882 [details], which scratches one of my few itches I had with Mozilla - I just installed it and it seems to work with Mozilla Firebird 0.6 as well. I personally don't really need an additional button for this - having the ALT+UP key combination is already a big relief. I also use KDE's Konqueror quite intensively (which already had this feature for quite a while) and I was really missing this in Mozilla/Phoenix/Firebird. Galeon implemented an Up-Button as well, but I prefer the keyboard shortcut. This bug has been open for more than three years now and according to the number of duplicates there seems to be some general interest in this feature. A patch is available as well - what is missing so it finally gets implemented, at least as a keyboard shortcut? I gave this bug my vote, but I fear it won't change much...

if there is a patch, the reporter could mark it "blocking 1.4: '?'".

Well, let's try it then :)

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

Will this be implemented for Firebird's XUL FTP view?

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

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

Who'd have thought ;-)

Fix checked in to the trunk.

Comment on attachment 216109 [details] [diff] [review] more bitrot a=me for SeaMonkey 1.1

(In reply to comment #101) > Created an attachment (id=216109) [edit] There is some strange code in this attachment. +function BrowserUp() +{ + loadURI(getBrowser().currentURI.spec.replace(/[#?].*$/, "").replace(/\/[^\/]*.$/, "/")); +} This removes trailing parts starting at # or ?, and then removes the last directory. This means that the code would change www.foo.org/bar/?baz to www.foo.org/, but I would prefer change it to only www.foo.org/bar/ A better solution would be (1) to remove the trailing part starting with # or ?, (2) is there's no such part, then remove the trailing directory. Maybe additionally if (2) failed as well, (3) remove the leftmost domain name part. This should look like var s = getBrowser().currentURI.spec; if (s.match(/[#?].*$/)) loadURI(s.replace(/[#?].*$/, "")); else if (s.match(/\/[^\/]*.$/)) loadURI(s.replace(/\/[^\/]*.$/, "/")); else if (s.match(/^[^\.]*\..*\..*/)) loadURI(s.replace(/^[^\.]*\.(.*\..*)$/, "$1")); This code assumes that getBrowser().currentURI.spec gives a string containing no http:// (or any other protocal part). If (3) goes in, then this check: + if (upDisabled != !browser.currentURI.spec.replace(/[#?].*$/, "").match(/\/[^\/]+\/./)) { should be updated appropriately.

Sorry, I'd checked the fix in to the branch before reading your comment. What I was trying to do was to avoid splitting at a / after a ? or #.

(In reply to comment #105) > Sorry, I'd checked the fix in to the branch before reading your comment. > > What I was trying to do was to avoid splitting at a / after a ? or #. Indeed! But then you remove /both/ query part /and/ the last directory. It might be useful to remove them "one by one", first query part, then the last directory. Another good addition might be to remove the leftmost part of the domain name (if it contains at least 2 dots) in the case when there's neither query part nor subdirectories (that is done in the code fragment for the function BrowserUp() in the comment #104, "else if (s.match(/^[^\.]*\..*\..*/)) loadURI(s.replace(/^[^\.]*\.(.*\..*)$/, "$1"));")

The mentioned problem applies only to the (extremely rare) special case of a URL where query parameters are applied to a directory. In 99% of all URLs with query parameters, there is a file name between the last / and the ?, and the "Up" command definitely wants to remove both (just removing the query parameters almost always leads to a nonsensical URL). I therefore contend that the code as already reviewed and checked in should not be changed.

(In reply to comment #107) > The mentioned problem applies only to the (extremely rare) special case of a > URL where query parameters are applied to a directory. It applies, for example, to the page https://bugzilla.mozilla.org/show_bug.cgi?id=33684#add_comment, which I am currently looking at. So this case is not so /extremely/ rare, I suppose. :)

(In reply to comment #107) Anyway, there's another reason for my code: it makes bugzilla.mozilla.org into mozilla.org, which should be a Good Thing.

> It applies, for example, to the page > https://bugzilla.mozilla.org/show_bug.cgi?id=33684#add_comment, which I am > currently looking at. So this case is not so /extremely/ rare, I suppose. :) Then I misunderstood your description of the problem. Either way, I am opposed to your proposed code because of what I mentioned. Your code would change this URL to https://bugzilla.mozilla.org/show_bug.cgi, which is nonsensical.

(In reply to comment #110) > Then I misunderstood your description of the problem. Either way, I am opposed > to your proposed code because of what I mentioned. Your code would change this > URL to https://bugzilla.mozilla.org/show_bug.cgi, which is nonsensical. Well, you are right here. But there are still 2 smaller issues: 1. The check for the possibility to go up is following: + if (upDisabled != !browser.currentURI.spec.replace(/[#?].*$/, "").match(/\/[^\/]+\/./)) { So it checks whether there is a subdirectory after removing query part. The procedure BrowserUp() removes both of them. This disallows going up from the addresses like www.foo.org/?search or www.foo.org#bottomlabel. 2. The issue mentioned in comment #109 is still open.

Well, I think "Up" from http://www.bbc.co.uk/radio/#musiclinks should go to http://www.bbc.co.uk/ and I don't think "Up" should try to go further up.

(In reply to comment #112) > Well, I think "Up" from http://www.bbc.co.uk/radio/#musiclinks should go to > http://www.bbc.co.uk/ and I don't think "Up" should try to go further up. IMHO going further up might be useful for addresses like http://news.yahoo.com/, http://apazhe.livejournal.com/, http://azureus.sourceforge.net/ or http://sessionsaver.mozdev.org/. However, you are the person to decide. Anyway, thanks a lot for implementing the feature!

Has this fix been released yet? (I do not find the up button, not even in the configure toolbars dialog, in version 2.0.0.2, which was released 2007-02-23, almost a year after the fix.) Where is the link to the commit (WebSVN or equivalent) so I can check where the fix ended up?

(In reply to comment #114) >where the fix ended up? Strangely enough, in SeaMonkey 1.1a, as per the keyword.

Oh, I was just using latest www-client/mozilla-firefox and thought that the fix would eventually show up in some update. Now I got tired of waiting. Seems like I have to switch to www-client/seamonkey (and set USE="moznocompose moznoirc moznomail moznoroaming" to cut some overweight). I did not keep track of all those funny names; I should read up on the whole bunch of Mozilla/Firefox/Seamonkey/Thunderbird/Iceweasel/whatever.

The equivalent bug for Firefox is bug 205844.

And there are Firefox extensions that support "Up" navigation. /be

Now I built www-client/seamonkey-1.1.1 but there is no Up button in it (only Back, Forward, Reload, Stop). There is also no context menu when rightclicking on the buttons, that would let the user configure the toolbar (add missing buttons) like in www-client/mozilla-firefox-2.0.0.2. So it seems like version 1.1.1 is older than 1.1a. But I am not sure since I do not know what "1a" is supposed to mean. It could be a hexadecimal number or some other kind of code.