Closed
Bug 308089
Opened 19 years ago
Closed 10 years ago
'Back' and 'Forward' buttons broken, under certain conditions
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: tombraun, Unassigned)
Details
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.
Comment 1•19 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
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 4•19 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•19 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
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.
Comment 7•18 years ago
|
||
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•18 years ago
|
||
a dup of bug 314362?
Comment 9•18 years ago
|
||
This isn't about focus, as far as I can tell.
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Comment 10•13 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.
Comment 11•10 years ago
|
||
404 Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•