'Back' and 'Forward' buttons broken, under certain conditions

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
13 years ago
5 years ago

People

(Reporter: tombraun, Unassigned)

Tracking

1.8 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4


This bug possibly could have been filed under the 'history' component, but I'm
not sure, so I file it here.

I wish I could give a sample URL, but I can't since this happens with an
internal, corporate application.  So I will have to describe the problem
somewhat verbosely.

The problem did not happen with previous versions of Firefox, or with any other
browsers.  Since the 'back' and 'forward' button navigation was improved for
this release (FF1.5 beta 1), I assume that these changes are what cause the problem.


In short
========
When browsing through a certain security proxy, it can happen that a page
appears more than once in the small history of the last pages, which is visible
when pressing on the small down-ward arrow next to the 'back' or 'forward' button.

Once a page appears twice in a row in there, the back or forward button will not
be able to navigate over them.  In effect, once those entries are reached the
button stops working.

Selecting the next page manually from that little pull-down history, however,
still works perfectly well.


In more detail
==============
We have a corporate security application here at work.  It's a proxy
(excplicitly configured under the connection settings).  When it sees that we
are accessing certain pages, it returns its own content instead.  This content
is a frameset with two frames panels.  One contains a message, the second one
contains the original page.  Since the proxy replaces the returned data with the
frameset, the URL that is shown in the URL field is still the same as that of
the original page.  The proxy also stores this URL temporarily, so that the
request for the content frame-panel does not get intercepted again.

So, anyway, all of this works perfectly well.  An additional feature now is that
the proxy will detect when we click on any link within that frameset.  It uses
the referer HTTP header for this.  Once it detects that, it injects a page with
some JavaScript that breaks out of the frame, and then relocates to the original
URL.  

As an end-result, you can occasionally see some framed pages, but with the
original URL, and then break out of the frame, automatically, with the next
click on any link.

All of this still works well.  However, when I click on something, and the
break-out page is generated, the under some circumstances (it happens with some
sites but not with others), there will be two entries for that very same page in
the small pull-down history.  Once those two entries are generated, I cannot
navigate backwards over them with the 'back' button.

Since the next page is visible in the small pull-down history, it appears that
it should be possible for the browser to figure out where to go.  But the fact
that the same page appears twice in a row in that short history seems to cause
problems.  Maybe the fix is as simple as preventing two identical entries in a
row in that short list?  What do I know, I haven't seen the code.  Just a guess...

Since this proxy, weird as it is, is complient with various protocols (as far as
we can tell) and represents one of the many strange applications that are in use
in various corporate environments, I could imagine that with the updated 'back'
and 'forward' features, a variety of different corporate applications might be
broken.

Sorry I can't give you sample code, since this is proprietary.  However, if you
need any help, test-runs or more data, please don't hesitate to contact me.

Tom


Reproducible: Always

Steps to Reproduce:




I'm filing this as a major bug, since there is the potential that different
in-house corporate applications might be broken now.
(Reporter)

Updated

13 years ago
Version: unspecified → 1.5 Branch

Comment 1

13 years ago
The back/forward buttons are disabled. The right click menu is available on each
button for navigation. 
Env:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
(Reporter)

Comment 2

13 years ago
I now have a test case available!  You can find it here:

   http://www.tombraun.com/cgi-bin/test/first.cgi

For maximum effect, erase your current history, or open a new tap (with an
empty history).

1. Go to that URL.
2. You will see a simple page, with a single link in it, called 'A'.
   Click on that link.  It will load the file 'a.cgi'.
3. Two frames will appear.  The top frame just contains a plain message.  The
   bottom frame again contains 'a.cgi' again.  However, 'a.cgi' returns
   different content the second time around, and therefore does not create 
   another frameset.  You just see some text and a link to 'B'.
4. Click on the link labeled 'B'.  This loads 'b.cgi'.  You will see some
   activity.  'b.cgi' breaks out of the frame.  You now see some more text
   and a link to 'C'.  Click on it.
5. 'c.cgi' displays some text, and allows you to start over again.

When you are at the last page ('c.cgi'), go to the history of the back button.
You will find that 'A' appears twice in it!  If you repeatedly press the back
button, you will notice that you will get stuck at 'A'!

That is exactly the issue I am talking about.  Something happens along the way, 
which prevents the browser from the continued traversal of the back history.

Interestingly, with this test case, I can even reproduce this for older
versions of Firefox.  But with older versions, I never see this on real-world
sites, only on the test site.  However, with FF1.5, I see this quite often
in real-world sites as well.

In some cases, I see the two entries, but I can traverse them.  In other cases,
I cannot do that, and get stuck at the double entry.

I hope this test case helps with a quick resolution of the problem.  Obviously,
those various CGI scripts are written to simulate the behavior of the proxy,
which will return different content for the same request.  If you would like
to have a copy of those CGI scripts, just let me know.

It still appears to me that as a quick fix, it should be possible to prevent
entries from being written in the history, if they are the same as the last
entry.  But as I said, I have not seen the code, so what do I know.

If you have any questions, or if I can help in any way, please let me know.

Thank you very much!

Tom

Comment 3

13 years ago
i can confirm this on Firefox 1.5b2  

Comment 4

13 years ago
I have also found this bug using FF1.07.  A sample link is http://www.msnbc.msn.com/id/9787692/site/newsweek/.  After navigating to this page from the main MSNBC site, the site loads fine, with no extra history.  Wait 5-10 seconds and watch for browser activity.  Check your history and you will have 2-4 "Backs" of the same page, none of which work.  To get back, you will have to select the item in history.  If you do this with a tabbed window, the NBC peacock will show up as the tab's icon at first, but after the browser activity, the icon changes to a two-tone grey icon with a W--no idea what site it is.    Furthermore, if you go all the way back in history, all is fine...sort of.  If you then use the Forward history to select all the way ahead, your forward arrow is still active.  Checking that arrow's history brings up a very small, empty drop-down box!  I've seen this problem repeatedly on MSNBC's site, but have yet to notice it elsewhere.  My cache is 10000kb, I'm on WinXP Pro SP2, AMD Athlon XP 2600+, 512MB memory, 80gb drive.

Comment 5

13 years ago
To see if it is a problem with fastback, try setting browser.sessionhistory.max_total_viewers preference in about:config to 0.
Component: General → History: Session
Product: Firefox → Core
QA Contact: general → history.session
Version: 1.5 Branch → 1.8 Branch

Comment 6

13 years ago
Ditto this on 1.07 on XP. I cant improve on Andrew Knopps description. It is exactly as he states...and a very annoying bug. The newsweek site is a perfect test case... as all (especially multi-page) articles exhibit this behavior.
So... on the testcase in comment 2, what is the bug, exactly?  The session history should show a FIRST, an A (from loading the frameset), another A (from loading a new page in one of the frames), then a B (which the page breaks out of the frame to).  One could argue that we should disambiguate the two A's in the menu, but there are bugs on that.

Now when you go back to the second A, it immediately runs the same JS that sent it to B to start with.

Note that if the script called location.replace(), that would be a different story, I suspect.  But it doesn't.  Setting location.replace to a string does nothing useful whatsoever.

Tom, does actually calling location.replace() instead of setting location.href when breaking out of the frame solve your problem?

Comment 8

12 years ago
a dup of bug 314362?
This isn't about focus, as far as I can tell.

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell

Comment 10

7 years ago
I just want to confirm that I see this often, and I'm not on a corporate site. For instance, tonight when I navigated to www.csmonitor.com, I got two entries in the "back" listing. I then clicked on one particular article, and thence to a second page. There should have been two "back" button entries, one for each page, but there were three. When I go to Google+, I end up with many entries. It seems that each time the browser goes to fetch more information on a page, it adds another entry, even though I haven't overtly navigated anywhere.

What's odd is that sometimes the "back" button skips over the duplicates, but not always.
404
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.