33684 - add "Up" navigation command

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, enhancement, P3)

Description

[Jeremy M. Dolan]

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.

Comment 1

[Jeremy M. Dolan]

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.

Comment 2

[Matthew T (active 1999-2002)]

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?

Comment 3

[Jeremy M. Dolan]

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* =)

Comment 4

[Gervase Markham [:gerv]]

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

Comment 5

[Jeremy M. Dolan]

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?

Comment 6

[Asa Dotzler [:asa]]

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

Comment 7

[Eli Goldberg]

I have no opinion, and defer to Brendan. 

Comment 8

[Brendan Donohoe]

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.

Comment 9

[Eli Goldberg]

Resolving/verifying as WONTFIX per brendan's comments.

Jeremy, please feel free to re-open this bug, assign it to [e-mail], 
and mark it with a helpwanted keyword, in case a mozilla contributor would like 
to implement it for Mozilla.

Comment 10

[Eli Goldberg]

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

Comment 11

[Jeremy M. Dolan]

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.

Comment 12

[Eli Goldberg]

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

Comment 13

[David Hugh-Jones]

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

Comment 14

[Jesse Ruderman]

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

Comment 15

[Andrew Thompson]

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

Comment 16

[Andrew Thompson]

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.

Comment 17

[Jeremy M. Dolan]

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.

Comment 18

[Mike Young]

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.

Comment 19

[Mike Young]

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

Comment 20

[Mike Young]

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

Comment 21

[Simon Montagu :smontagu]

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.

Comment 22

[Johan Walles]

Jeremy, as per Eli Goldberg's comment from 2000-03-29 14:12, can't you re-open
this bug, assign it to [e-mail] 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!

Comment 23

[Johan Walles]

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!

Comment 24

[Mike Young]

Due to continued interest in this bug, I am opening and assigning to 
[e-mail]. 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

Comment 25

[Mike Young]

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

Comment 26

[[e-mail]]

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

Comment 27

[[e-mail]]

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.

Comment 28

[Johan Walles]

In response to [e-mail], 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.

Comment 29

[timeless]

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

Comment 30

[[e-mail]]

Attachment: patch for Go/Up

Comment 31

[Mike Young]

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://[e-mail]: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...

Comment 32

[Mike Young]

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 [e-mail] 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.

Comment 33

[timeless]

.

Comment 34

[Jesse Ruderman]

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

Comment 35

[Mike Young]

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

Comment 36

[[e-mail]]

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.

Comment 37

[Mike Young]

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.

Comment 38

[Jesse Ruderman]

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

Comment 39

[Mike Young]

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)

Comment 40

[Jesse Ruderman]

Sorry, I meant to link to bug 57192.

Comment 41

[Blake Ross]

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

Comment 42

[[e-mail]]

Attachment: removed anchors and queries before going up

Comment 43

[timeless]

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

Comment 44

[Mike Young]

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.

Comment 45

[[e-mail]]

Is this bug just going to stagnate further?

Comment 46

[Jesse Ruderman]

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

Comment 47

[[e-mail]]

Attachment: improved regexp

Comment 48

[Jeremy M. Dolan]

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*

Comment 49

[Johan Walles]

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.

Comment 50

[Mike Young]

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.

Comment 51

[[e-mail]]

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

Comment 52

[Brendan Eich [:brendan]]

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

Comment 53

[Mike Young]

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.

Comment 54

[[e-mail]]

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

Comment 55

[Jesse Ruderman]

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

Comment 56

[Mike Young]

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.

Comment 57

[Jesse Ruderman]

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

Comment 58

[[e-mail]]

Attachment: patch using web navigation

Comment 59

[Mike Young]

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

Comment 60

[Matthew T (active 1999-2002)]

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.

Comment 61

[Jesse Ruderman]

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

Comment 62

[Brendan Eich [:brendan]]

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

Comment 63

[Mike Young]

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

Comment 64

[Jeremy M. Dolan]

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?

Comment 65

[Jesse Ruderman]

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

Comment 66

[Brendan Eich [:brendan]]

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

Comment 67

[Jeremy M. Dolan]

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

Comment 68

[Jesse Ruderman]

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.

Comment 69

[[e-mail]]

Attachment: Patch to fix bitrot

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

Comment 70

[Mike Young]

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 71

[timeless]

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 72

[Alex Vincent [:WeirdAl]]

Attachment: Suggested fix with testcase demonstrating effectiveness

Comment 73

[Alex Vincent [:WeirdAl]]

Attachment: Adjusted testcase for root directory

Comment 74

[Alex Vincent [:WeirdAl]]

Comment on attachment 60966 [details]
Adjusted testcase for root directory

Sorry, it's wrong again.  Forgot another obvious test.	New attachment in one
moment.

Comment 75

[Alex Vincent [:WeirdAl]]

Attachment: Suggested patch with testcase, take 3

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.

Comment 76

[Alex Vincent [:WeirdAl]]

Replace
if (url == "http:/") {

with 
if (url.length == url.indexOf("/") + 1) {

Forgot about non-http:// protocols, such as file://

Comment 77

[[e-mail]]

Attachment: Patch to address timeless' comments

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.

Comment 78

[[e-mail]]

Attachment: bitrot spam

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

Comment 79

[Matthew T (active 1999-2002)]

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

Comment 80

[Jonadab the Unsightly One (Nathan Eady)]

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.  

Comment 81

[Jeremy M. Dolan]

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)

Comment 82

[Dan Tobias]

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.

Comment 83

[[e-mail]]

Attachment: Package that adds "up" to Go menu

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

Comment 84

[[e-mail]]

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

Comment 85

[Jesse Ruderman]

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.

Comment 86

[timeless]

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

Comment 87

[Jo Hermans]

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.

Comment 88

[Blake Ross]

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

Comment 89

[[e-mail]]

Attachment: Phoenix-compatible package

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

Comment 90

[Robert Tolliver]

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

Comment 91

[Chris Lyon]

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

Comment 92

[Calvin Spealman]

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.

Comment 93

[Doug Harris]

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.

Comment 94

[Lenz Grimmer]

Thanks to [e-mail] 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...

Comment 95

[Peter Lairo]

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

Comment 96

[Lenz Grimmer]

Well, let's try it then :) 

Comment 97

[Sander]

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

Comment 98

[Grey Nicholson (they/them)]

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

Comment 99

[Jo Hermans]

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

Comment 100

[Steve England [:stevee]]

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

Comment 101

[[e-mail]]

Attachment: more bitrot

Who'd have thought ;-)

Comment 102

[[e-mail]]

Fix checked in to the trunk.

Comment 103

[Robert Kaiser]

Comment on attachment 216109 [details] [diff] [review]
more bitrot

a=me for SeaMonkey 1.1

Comment 104

[Vladislav Duma]

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

Comment 105

[[e-mail]]

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

Comment 106

[Vladislav Duma]

(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"));")

Comment 107

[Timwi]

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.

Comment 108

[Vladislav Duma]

(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. :)

Comment 109

[Vladislav Duma]

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

Comment 110

[Timwi]

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

Comment 111

[Vladislav Duma]

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

Comment 112

[[e-mail]]

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.

Comment 113

[Vladislav Duma]

(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!

Comment 114

[esigra]

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?

Comment 115

[[e-mail]]

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

Comment 116

[esigra]

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.

Comment 117

[Jesse Ruderman]

The equivalent bug for Firefox is bug 205844.

Comment 118

[Brendan Eich [:brendan]]

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

/be

Comment 119

[esigra]

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.