Open Bug 187187 Opened 22 years ago Updated 2 years ago

Improving 'forward button' functionality by retaining its history as long as possible

Categories

(Core :: DOM: Navigation, enhancement)

enhancement

Tracking

()

People

(Reporter: thomas-mzll-01, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212

The inspiration for this feature request is the slashdot comment linked at the
URL above. The comment was in regards to an article discussing the redesign of
the "back button functionality." His comment was essentially: the forward button
is what needs to be improved. Why is the forward history erased if you go back
and go to another page? There's no need to erase the forward history until you
go back, click a link (or bookmark), and then GO BACK AGAIN. 

I do NOT think this feature will be confusing for new users, either.

Reproducible: Always

Steps to Reproduce:
1. Browse the web.
2. Hit the back button a couple times. (Now you have a couple pages in your
'forward button history.'
3. Click a link or a bookmark.
Actual Results:  
The 'forward button history' was wiped clean. There is no easy way to get back
to those pages.

Expected Results:  
The 'forward button history' should be retained until the person hits the back
button again. At this point two things could happen. The previous 'forward
history' could be retained, and the last page visited could be prepended to the
forward history, or the forward history could be flushed, and only the previous
page added to it. The point is not to wipe out the forward history until its
absolutely necessary.
Here is an example in case my original comments were hard to understand.

*** HOW THINGS WORK NOW ***

1. Visit www.mozilla.org

2. Visit www.microsoft.com

3. Visit www.ebay.com

4. Press the back button (now you are at microsoft.com, and ebay.com is in your
forward history)

5. Press the back button again (now at mozilla.org, microsoft/ebay are in
forward history)

6. Click a link on mozilla.org's page (now your forward history is erased)

*** HOW THINGS SHOULD WORK ***

Steps 1 - 5 from above remain the same.

6. Click a link on mozilla.org's page, e.g. to bugzilla. You are currently at
bugzilla.mozilla.org. Your forward history remains: microsoft.com, ebay.com.
Your back history is: mozilla.org.

7. Press the back button. Now you are back at mozilla.org. Your forward history
now contains: bugzilla.mozilla.org, microsoft.com, ebay.com.

*** ALTERNATE ENDING ***

I could also see step 7 going like this:

7. Press the back button. Now you are back at mozilla.org Your forward history
now contains: bugzilla.mozilla.org.

Hope that makes it a bit clearer. 
I have a better idea.

The history of pages should not be treated like a stack.
The stack shold not be implemented in such a way that one click can pop the
whole stack.

The history should be a linked list.  New page visits should be INSERTED into
the list at the current location.

Example:  Visit pages w,x, and y.  Click Back to get to x, then visit z.

Old way, y is popped, z is pushed, and Forward button is disabled.  History is
w,x,z and user is at z.

New way, z is inserted into the list, giving a history of w,x,z,y.
User is at z, Forward goes to y and Back goes to x.

The best part is the Back button's functionality doesn't change at all.

Having page y and everything after y vanish is the reason I open lots of browser
windows with "Open Link in New Window".  What I'm really doing by opening a new
window (or tab) is preserving the Forward button's history in the old window.

(See also bug 21521 and recent discussion on Slashdot.)
Yes, I agree. I think you just explained the original idea in programming terms.
Thanks! :-)

Maybe this will be a feature I can use to get acquainted with the mozilla code...
Went looking for ways to implement this.
No, I'm not familiar with Mozilla's source.
These are just guesses.  Don't know if they work.

mozilla/xpfe/components/shistory/src/nsSHistory.cpp
  line 147 (comment "A little tricky math...")
-  mLength (++mIndex + 1);
+  mLength++;

mozilla/xpfe/components/shistory/src/nsSHTransaction.cpp
  line 107 (function "SetNext")
-  #if 0
+  #if 1

I get the impression this idea had already been thought of.
And not enabled for fear of running out of memory (with phrases
such as "unbounded growth" in the comments).
Contrary to the fears in the comments, I don't think memory
is a problem.  That problem has to be (and is) dealt with for
the Back button anyway.  Should be easy to do the same for the
Forward button.
Figured a way to do it:

mozilla/xpfe/components/shistory/src/nsSHistory.cpp
  line 147 (comment "A little tricky math...")
-  mLength (++mIndex + 1);
+  ++mIndex;
+  mLength++;

mozilla/xpfe/components/shistory/src/nsSHTransaction.cpp
  line 111 (function "SetNext")
+  NS_ENSURE_SUCCESS(aNext->SetNext(mNext), NS_ERROR_FAILURE);

Do you know if this will have a performance hit?

If you visit a, b and then c, click back to b and then go to bookmark d and then
click on link e what happens?

Does it go a, b, d, e, c or a, b, d, c, e ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
No performance hit.  The history is a linked list.  Inserting into a linked list
takes the same time (big O time) as appending.

Your example would end up with your first list: a, b, d, e, c.

Minor correction:  in my previous posts
"-  mLength (++mIndex + 1);" should be
"-  mLength = (++mIndex + 1);"
This is a feature I wanted for a long time - just wanted to finally post it to
Bugzilla, but - surprise, I'm not the first one to think of that:) What an
innovative community:)

So how is the progress on this very needed IMO feature?
This way the forward-button could finally get a popup-menu, too (little arrow
below), like the back-button :)

Hugh
Sounds like a duplicate of bug 187410.
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
Assignee: radha → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.