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
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
i can confirm this on Firefox 1.5b2
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.
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
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?
a dup of bug 314362?
This isn't about focus, as far as I can tell.
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
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.