Closed Bug 33684 Opened 25 years ago Closed 18 years ago

add "Up" navigation command


(SeaMonkey :: UI Design, enhancement, P3)



(Not tracked)



(Reporter: jmd, Assigned: neil)



(Keywords: fixed-seamonkey1.1a)


(3 files, 10 obsolete files)

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

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

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'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 
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).
Assignee: cbegle → bdonohoe
Component: Browser-General → User Interface: Design Feedback
Ever confirmed: true
QA Contact: asadotzler → elig
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, 
and mark it with a helpwanted keyword, in case a mozilla contributor would like 
to implement it for Mozilla.
Closed: 25 years ago
Resolution: --- → WONTFIX
Verifying as WONTFIX. (Yeah, Matthew...)
Is it possible to add a hook for it, and just not a button in the default 

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:

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:


--Steve Kangas at

This doesn't solve the -> 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 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 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
Keywords: helpwanted
Resolution: WONTFIX → ---
Summary: "Up" navigation → "Up" navigation button
reassigning because you cant reopen and reassign at the same time. (Sorry for 
the spam)
Assignee: bdonohoe → nobody
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, 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...
Attached patch patch for Go/Up (obsolete) — Splinter Review
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

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

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. 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
But I'm sure others would disagree... 

adding patch keyword...
Keywords: patch
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 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.
Component: User Interface Design → XP Apps: GUI Features
Keywords: review
Target Milestone: --- → mozilla0.9.3
Assignee: nobody → youngfam
QA Contact: elig → blake
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.

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. :-)
Assignee: youngfam → neil
QA Contact: blake
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
+  if (upDisabled != !_content.location.href.replace(/#.*$/, 
"").replace(/?.*$/, "").match(/\/[^\/]+\/./))
i think the replaces can be improved based on this example:

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?
Assignee: neil → blakeross
QA Contact: sairuh
Target Milestone: mozilla0.9.4 → mozilla0.9.5
See also bug 12707, nothing to click on at local directory listings to go up a 
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.5
Attached patch improved regexp (obsolete) — Splinter Review
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.
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.
Summary: "Up" navigation button → "Up" navigation command
Blocks: 89005
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

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().
Depends on: 61886
See also bug 102909, "No keyboard access to link toolbar".
Target Milestone: mozilla0.9.5 → mozilla0.9.6

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
The links toolbar wasn't held up for bug 61886, so this bug shouldn't be held 
up for it either.
Attached patch patch using web navigation (obsolete) — Splinter Review
Target Milestone: mozilla0.9.6 → mozilla0.9.7

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.
Assignee: blakeross → neil
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 

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.

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?
Keywords: helpwanted
Summary: "Up" navigation command → add "Up" navigation command and button
Adding a button is bug 89005, which is blocked by this bug and by the lack of 
customizable toolbars.
Summary: add "Up" navigation command and button → add "Up" navigation command
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!

> 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.
Attached patch Patch to fix bitrot (obsolete) — Splinter Review
Updated patch in the off-chance that it will make 0.9.7 :-)
Attachment #41403 - Attachment is obsolete: true
Attachment #43505 - Attachment is obsolete: true
Attachment #49882 - Attachment is obsolete: true
Attachment #52492 - Attachment is obsolete: true

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

>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 ( i don't see the point in this being here...
Attachment #60813 - Flags: needs-work+
Attached file Adjusted testcase for root directory (obsolete) —
Attachment #60965 - Attachment is obsolete: true
Comment on attachment 60966 [details]
Adjusted testcase for root directory

Sorry, it's wrong again.  Forgot another obvious test.	New attachment in one
Attachment #60966 - Attachment is obsolete: true
This testcase checks for "" and returns
"".  The second testcase, marked obsolete, returns
"".  I don't know which is correct in this instance.
if (url == "http:/") {

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 because it's not a valid URL.
Attachment #60813 - Attachment is obsolete: true
Attachment #61067 - Flags: review+
Attached patch bitrot spam (obsolete) — Splinter Review
Sorry about the SPAM, but I forgot to use cvs update -A :-(
Attachment #61067 - Attachment is obsolete: true
> 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:
Target Milestone: mozilla0.9.7 → mozilla0.9.8
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.
Attached file Package that adds "up" to Go menu (obsolete) —
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.
Target Milestone: mozilla0.9.8 → Future
*** Bug 153696 has been marked as a duplicate of this bug. ***
Blocks: 157199
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, 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.
Blocks: 123569
No longer blocks: 157199
*** 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?
Attachment #66110 - Attachment is obsolete: true
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 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, the menu provides the
following options:

The options for a page such as this 
( would also include an option
to go to

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 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 :) 
Flags: blocking1.4?
Flags: blocking1.4? → blocking1.4-
*** 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. ***
Product: Core → Mozilla Application Suite
*** Bug 300457 has been marked as a duplicate of this bug. ***
Attached patch more bitrotSplinter Review
Who'd have thought ;-)
Attachment #61233 - Attachment is obsolete: true
Attachment #216109 - Flags: superreview?(jag)
Attachment #216109 - Flags: superreview?(jag) → superreview+
Fix checked in to the trunk.
Closed: 25 years ago18 years ago
Resolution: --- → FIXED
Attachment #216109 - Flags: approval-seamonkey1.1a?
Comment on attachment 216109 [details] [diff] [review]
more bitrot

a=me for SeaMonkey 1.1
Attachment #216109 - Flags: approval-seamonkey1.1a? → approval-seamonkey1.1a+
(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 to, but I would prefer change it to only

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

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, 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 into, which should be a Good Thing.
> It applies, for example, to the page
>, 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, 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, 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 or
2. The issue mentioned in comment #109 is still open.
Well, I think "Up" from should go to and I don't think "Up" should try to go further up.
(In reply to comment #112)
> Well, I think "Up" from should go to
> and I don't think "Up" should try to go further up.

IMHO going further up might be useful for addresses like,, or However, you are the person to decide.

Anyway, thanks a lot for implementing the feature!
Depends on: 355396
Blocks: 371969
Has this fix been released yet? (I do not find the up button, not even in the configure toolbars dialog, in version, 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.

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-

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.
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.