23926 - Add "Referring Page" item to Go menu

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[Sean Richardson]

In bug 22788, "[RFE] Spawned windows should inherit previous page in history",
[e-mail] suggests not doing that because sometimes the only way to
tell if a page is in a new window is by the greyed-out [Back] and [Forward]
buttons, and then says:
   >given all that I would still like to see some way to know from where new
   >windows were spawned.

Suggested: a "Referring Page" item on the "Go" menu, which would do exactly
that: go to the page that the current page was arrived at from. For any
page forward of the root of a window's Session History, this would be exactly
equivalent to the [Back] button, but when at the root of the Session History
(greyed buttons) or "earlier", it would allow going back one page to the page
that a new window was reached from, which the greyed [Back] button would not
allow.

This would require the same sort of pan-window session history asked for
by bug 18808 under the hood, but it would be hidden behind the "Referring Page"
menu item, rather than available at all times, preserving the rootedness of
the Session History in each window while allowing the user to go back further
if desired.

This is suggested because the persistent history, if it stores the navigation
path at all, does not make it visible in NN 4.7 or (so far, at least) in
Mozilla, so it is of no use for answering the questions, How did I get here?
and, What was that page two pages ago? (I wanted to bookmark that!).

Comment 1

[Sean Richardson]

oops, setting severity to enhancement...

Comment 2

[Claudius Gayle]

yeah what he said. seriously, I think this is a great enhancement, that's my vote.
sairuh: I'm not sure if this is me or you, but for now let's just say it's you ;-)

Comment 3

[Chris McAfee]

m15

Comment 4

[don]

Move to M16 for now ...

Comment 5

[Matthew T (active 1999-2002)]

Implementing this only makes sense if bug 22788 is implemented first (and I don't 
think it should be). However, 22788 is scheduled for M20, but this bug is 
scheduled for M16. What gives?

Conversely, if bug 18808 is fixed, this bug becomes obsolete.

In about 98% of cases, a `Referring Page' item would do exactly the same as the 
`Back' item. Therefore, users would never realize that the two items were 
distinct, unless they happened to open the `Go' menu where all of the following 
circumstances were in effect simultaneously: (a) the current window had been 
spawned from a previous window; (b) the current window was at the start of its 
history; and (c) the user was paying attention, and noticed that `Back' was 
disabled but `Referring Page' wasn't.

That combination of events is going to be pretty rare, so I don't think this 
`feature' is worth it.

Comment 6

[sairuh (rarely reading bugmail)]

sounds like this is more History-oriented than the generalness of XPApps. over
to claudius :-)

Comment 7

[Alec Flett]

Taking these history and history-related bugs.

Comment 8

[Viswanath Ramachandran]

nav triage team: not a beta stopper

Comment 9

[Alec Flett]

argh.. take two at reassigning history bugs to new owner

Comment 10

[Blake Ross]

cc'ing marlon for UE input.

Comment 11

[Blake Ross]

-> ben, ruler of the go menu

Comment 12

[Jesse Ruderman]

This feature is available as a bookmarklet:
http://www.squarefree.com/bookmarklets/misc.html#go_to_referrer

Comment 13

[Jesse Ruderman]

Since this bug report requests a change to a menu, I'm moving it from Core to Mozilla Suite.  Bug 321302 is the equivalent bug for Firefox.

Comment 14

[Philip Withnall (unavailable)]

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

Comment 15

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".