287277 - back menu session history should be unbounded

Status: RESOLVED WONTFIX

(Firefox :: Menus, enhancement)

Description

[Jeff Leigh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Currently the back menu is limited to 15 items. This is arbitrary and very small
considering monitor resolutions these days. 30-40 items could easily fit on the
screen without any scrolling.

If you need to go back more than 15 pages you must open the menu, select the
bottom item, wait for the page to load, open the menu again, repeat. This is not
good user interface design.

At the very least I would like to see a pref added to change the size of the
back menu list. People who want more than 15 items can go in to about:config and
change it. Everyone else can leave the default and be happy with it. Doesn't
even need a GUI addition to the pref pane.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Jesse Ruderman]

asqueella, why did you change the summary from "Back menu session history should
be unbounded" to "pref to change the maximum number of items in Back/Forward
menus (without UI)"?  Those seem to be different requests.

Comment 2

[Nickolay_Ponomarev]

Oops. I think I didn't pay enough attention. My apologies, reverting. Sorry for
the bugspam.

Comment 3

[Wayne Mery (:wsmwk)]

*** This bug has been confirmed by popular vote. ***

Comment 4

[Marc Bejarano]

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

Comment 5

[Marc Bejarano]

this has annoyed me forever.  is there any reason at all not to turn this hard-coded constant into a hidden pref?

Comment 6

[Mike Connor [:mconnor]]

Because hidden prefs are the devil's work?  Having hidden prefs means extra code, as a general rule.  This isn't really something that's useful to enough people to justify the added code.

Remember, its not about "why not?" its about "why?"

Comment 7

[Jesse Ruderman]

It doesn't make any sense to wontfix an enhancement request on the grounds that *some* people suggested that it could be a pref, and it isn't worth a pref.

Making the menu unbounded, like the bookmarks menu, seems like a reasonable thing to do.  The fact that it's limited to 15 items gets in my way at least once a month and doesn't seem to serve any purpose.

(Note that there is a separate limit for how many session history entries are *stored*.  It is browser.sessionhistory.max_entries and seems to default to 50.)

Comment 8

[Mike Connor [:mconnor]]

I don't think that unbounded is desirable in any way at all.  The number of times someone is really looking for something more than 15 pages back in history is rare.  As you said, it gets in your way once a month, which should scream "corner case" to you.

Presenting a user with a really long list that they are unlikely to need really strikes me as overkill.  Others have rightly argued that the tools menu, at 11 items in 1.5, was a little long.  A 30 item menu to save an extra back navigation is just plain wrong.

FWIW, IE caps at 10, and I'm not sure they're wrong to pick an even shorter number.

Comment 9

[Jesse Ruderman]

> The number of times someone is really looking for something more than 15 pages > back in history is rare.

But the number of times my session history is more than 15 pages long is almost as rare.  That is, when my session history is that long, there's a pretty high chance that I will want to jump back more than 15 pages through my session history.

> As you said, it gets in your way once a month, which should
> scream "corner case" to you.

This isn't as rare as you seem to think.  Suppose I find myself at http://www.ok-cancel.com/comic/29.html and start reading the comics in reverse chronological order.  Once I've read the first 29 comics, I want to go back 28 pages in session history so I can read the remaining comics in chronological order.

If you haven't already mentally substituted "comics" with "porn images", please do so now.

> Presenting a user with a really long list that they are unlikely to need
> really strikes me as overkill.  Others have rightly argued that the tools
> menu, at 11 items in 1.5, was a little long.

The Tools menu contains commands; adding to it increases the number of items you have to scan to find the command you're looking for.  The back menu contains web pages you've visited very recently; making it unbounded doesn't make it any harder to go back 3 pages (even in the rare case where there are more than 15 pages in it).

Comment 10

[zug_treno]

(In reply to comment #7)
> (Note that there is a separate limit for how many session history entries are
> *stored*.  It is browser.sessionhistory.max_entries and seems to default to
> 50.)

Unfortunately just changing that pref doesn't work, see Core bug 197466. 

(In reply to comment #8)
> The number of
> times someone is really looking for something more than 15 pages back in
> history is rare.  As you said, it gets in your way once a month, which should
> scream "corner case" to you.
 
I encounter this daily while using a Saved Search here at b.m.o., but I realize that's not a common case.

Comment 11

[Marc Bejarano]

mike: while i understand why you don't like unnecessary code, i don't understand why you think hidden prefs are evil.  they serve a good purpose: allow power users to tweak settings that don't deserve a dedicated UI.

just because you consider having more than 15 entries in the back and forward buttons to be a "corner case" doesn't make it so.  just because IE doesn't let their users use their browser the way they'd like to doesn't make it good practice.

how much code is required to fetch a constant from a pref?  is your plan to kill all hidden prefs and hard-code them all?

having to go through the back menu over and over again when i want to go back a bunch of pages is no fun.  obviously i'm not alone in thinking this.

btw: safari gives you 30 items

Comment 12

[Marc Bejarano]

can somebody with the proper bits reopen this until there is more of a consensus reached?

or was mike's WONTFIX agreed upon by some mysterious powers that be?

Comment 13

[Mike Connor [:mconnor]]

That's not the way it works, sorry.  Try reading https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before you continue on this path.

Having screen-length menus is overkill, and I don't see any compelling reason to make a change to what is working.  Even in the extreme case, you have to go back 15 pages, and then 15 more pages.  If its a corner case, and can have a net effect of presenting way too much information at once to users when unnecessary, I'm not going to say ok to it.  That's the way we do things in general.  Adding hidden prefs is something we don't do as a rule, in the interest of minimizing codepaths, and the exceptions are generally few and far between.  See Ben's post on the subject here: http://weblogs.mozillazine.org/ben/archives/009620.html

Comment 14

[Marc Bejarano]

mike: ben's blog post talks about options being good when they apply to a "significant minority".  i'd argue that the vocal folks here and in bug 62010 (and their dupes) speak for a significant minority.  if you disagree (and i'd like to hear your reasons why), then i guess i should start lobbying for an extension :)

here's something else you many not have considered.  i've been in situations where my entire back button history list is populated with pages that are the result of POSTs.  if i choose any of them, i get the dialog box asking me to confirm that i want to POST, again.  what if i don't?  i'm stuck :(  i know.. you're going to call it a corner case.  but i've hit it a few times before and i doubt i'm the only one.

cheers,
marc

Comment 15

[Mike Connor [:mconnor]]

If you're hitting that many POST submissions in a row, I'll bet that the page has a "Home" link of some sort.  The inability to go back without resubmitting is a far worse bug that shouldn't affect this type of decision (I generally despise UI that is created to work around other bugs that should be fixed instead).

Another datapoint I should have mentioned: in the study that spawned bfcache, 39% of all page navigation is backwards to something < 10 entries back.  The vast majority of the rest, unsurprisingly, is forward navigation, so 15 items should cover the all but the most extreme cases.

One bug with four votes in a year, and five ccs, and another ancient bug with 30 ccs, and an entirely different solution currently proposed, falls FAR short of significant minority.  Significant, in that case, is usually > 20% of users, not 20 people in four years.

I think that if you're going to do an extension, it'd be interesting to explore the following heuristic, especially if you could really track the data properly:

- Make the back/forward menus show 10 items by default.
- If there are more than 10 items, have a small arrow entry, that when clicked expands to the maximum number of entries that can be displayed.
- Track the number of times users go back with the button or a keystroke, go back using the original menu, and go back using the expanded menu.

Data would be skewed by the people likely to use such an extension, but it'd be an interesting balance (small set that expands to fix the edge cases).  Still don't think adding code to the core is useful enough, but its an interesting idea to explore.

Comment 16

[Brian Salomaki]

The situation in #9 is similar to what I've run into that made me find this RFE:

> This isn't as rare as you seem to think.  Suppose I find myself at
> http://www.ok-cancel.com/comic/29.html and start reading the comics in reverse
> chronological order.  Once I've read the first 29 comics, I want to go back 28
> pages in session history so I can read the remaining comics in chronological
> order.

One additional solution that I thought of that could help this particular part of the problem (seems like it's one of the very common cases in which the session history would get that long at all) is to develop some sort of grouping strategy for history entries, based on things like closeness in time viewed, similarity of URL, and similarity of page title.  In Jesse's example and other ones I've run into (specifically today, photos shared on Facebook), all of the image pages have the same page title.

As a user, I'll often want to go back one image, go back to the first image (as in Jesse's case), or back to the page before the first image.  If I've looked at 30 images and they all have the same page title, it's unlikely that I'll want to go back to the 18th most recent image (because I won't even remember which one that is).  But wanting to go back to the oldest image or the most recent non-image both seem pretty natural.

Perhaps the menu could show the fifteen most recent items like it does now, but then if those 15 items are all similar enough to be grouped (by time, URL, title, etc.), then show a separator or a '...' or something to indicate that entries are being skipped, and then show the very first (oldest) element of the group and the page right before that (the most recent page not in the group).  Or, if there are only 16 or 17 images in the group, just expand the normal menu to cover those couple additional entries.

This certainly takes more code than just changing the size of the menu, but may serve everyone's purpose, allowing users to quickly get back to the pages they want to get back to, and preventing the menu from becoming unsightly.

Comment 17

[Marc Bejarano]

brian: i think your suggestion is excellent, but as you say, requires some real work.  would you mind creating a new bug with your RFE and we can make this bug depend on it?

Comment 19

[ti]

Not strictly this bug, but i was duped to this:

The total retained history should definitely be much more than 50 pages. I don't care about the menu (with fastback working, it's unnecessary), what matters is that an extension can be made that provides a more comprehensive history view (not a menu, long menues are indeed bad, I am thinking something like trailblazer or netsurf's history view)...

Where is this usability study mentioned as the reason for WONTFIX? I suspect what it measured is how similar the test browser is to IE based expectations which users put up with but Firefox should not clone.

(BTW I hit this limitation almost daily, not once a month as an other commenter remarked. It forced me to get used to opening links in new tabs if I may want to return to their origin page [but this way I end up with 500 tabs and unresponsive UI when I get distracted]).

Comment 20

[V@no]

Then at least make constant MAX_HISTORY_MENU_ITEMS as a global variable so it can be changed via an extension. As of now the only way is either repack omni.jar or rewrite entire FillHistoryMenu function.

Comment 21

[V@no]

Nowadays more and more website incorporate ajax/html5. They change url hash on each click (Google+, Facebook, other galleries). This allows fast content change without reloading the page. Each change in the url, however, adding new entry into session history. Watching 50 photos in one session is easy today, but going back to the original page become a pain, especially when we have to wait until the page loaded in order to able see next 15/7 pages to go back to.

What do we have right now:
1) The maximum number of session history user can jump to is 14, after that the max number reduces to 7 pages at a time (7 back, 7 forward)!

2) only 50 last pages saved in session history (but at least we have an evil hidden setting to overcome this ridiculous limitation: browser.sessionhistory.max_entries
Even with the 50 pages limit user must click 6 times before reaching the end of the entries.

3) going back/forward requires page change before it allow go further. It works ok if pages were cached, otherwise it could be a very slow process.

Mike, you should re-evaluate your views based on current web technologies.
Hopefully this bug will get reopened.