Closed Bug 216376 Opened 21 years ago Closed 16 years ago

Clicking a link, then the "Back" nav button does not position page at the link.

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 215405

People

(Reporter: emergingmoon, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 When clicking a link on a webpage then using the "Back" button to go back to the referring page, the positioning is reset to the top of the page. It would be handy if the page position was at the link clicked. Related to bug 215405, but that's for a Mozilla build, not Firebird. Reproducible: Always Steps to Reproduce: 1. Load a webpage -- preferably a long one (i.e. a Bugzilla query) 2. Click any link on the page that will open in the same window. 3. Use the Back button to go back to the previous page. Actual Results: Page position was reset to the top of the page. Expected Results: Page position should have been set to the link clicked.
Reporter, if you belive this to be the same as bug 215405, we should mark this one INVALID, since if this is a bug and it gets fixed in Seamonkey (Mozilla-the-suite), the fix will "carry over" to Firebird, as well.
It's not exactly the same because the bug I referenced only applies to one website; the problem I am reporting applies to every site you go to with Firebird. I provided the other bug for clarity if needed (although it looked like it mucked things up worse).
I believe this has something to do with the page being dynamically created. Not exactly sure if this helps though.
QA Contact: asa
Sites where the going back in history does jump to the right position on the previous page : http://slashdot.org/ http://www.eskimo.com/~scs/C-faq/top.html Sites where this does not happen : http://www.tweakers.net http://soapbox.wilwheaton.net/ I agree with one of the previous comments that it seems be correlate with dynamically created pages. I have tried the sites with these two versions of firebird : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5) Gecko/20031020 Firebird/0.7
*** Bug 226560 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031216 Firebird/0.7+ I was able to reproduce this bug. Those URLs provided by WJ Grootjans are correct. Slashdot does remember its position, whilst Tweakers.net does not. Is this a problem with how the website themselves are designed or is this something that Firebird can handle?
I'm still seeing this with the most recent 0.8 branch builds. I don't remember this happening before, pre 0.7 maybe. I've been playing with it but can't seem to find any consistencies in firebirds behavior For instance: While browsing http://www.samurize.com/modules/mydownloads/topten.php?hit=1 it seems to only happen every other time I hit the back button. Contrary to comment #4 I get this same behavior on http://slashdot.org but once again it is not every time, it is very random. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20040102 Firebird/0.7+
Using Firebird 0.7 in Win2k, I have noticed two flavours of this bug. 1. As referenced above, when using the back button on some pages (dynamic?) you are _always_ returned to the top of the page. 2. This also seems to occur less predictably with other (static?) pages. I really wish I could be more specific, but it seems like one in fifty times I click back, I am returned to the top of the page rather than the link location. There is a way to differentiate this second occurance from the first: upon clicking back and being returned to the top of the page, resize the browser window by dragging one of the edges. This will immediately move the page to the link location (where it should have been).
This seems to happen to me on sites that send a 'no-cache' header, which would be consistent with dynamic sites.
This still seems to be a problem on recent builds of Firefox (0.8/0.9) This problem hasn't been addressed for some time. Is it going to be fixed?
This still seems to be a problem on recent builds of Firefox (0.8/0.9) This problem hasn't been addressed for some time. Is it going to be fixed?
*** Bug 248700 has been marked as a duplicate of this bug. ***
I wonder if this is actually a Browser bug, rather than a Firefox one.
Well, I was wondering if anyone who knew what they were talking about, and knew whether it could be fixed or not, would be able to tell us at some point...
Comment 4 is bug 215405. Tweakers.net has a no-cache header , so does soapbox.wilwheaton.net. Slashdot.org does not. This is probably a dupe, but since there are some contradictory reports, setting DEPENDS.
Depends on: 215405
(In reply to comment #3) > I believe this has something to do with the page being dynamically created. Not > exactly sure if this helps though. I think this is new, I didn't notice it in 0.9. What I did notice though, was that it would try to go approx. the same distance down the page on dynamic pages, even if they had changed completely. Maybe this happened while trying to fix that?
This bug is still present in 1.0 PR. I wonder why the bug 217120 (scroll position in ebay) has been fixed but not this one. I suppose this one is more difficult to fix. What's sure is the Mozilla.org pages are best viewed in IE (perhaps should it be mentioned, after all ?). With Firefox, I've taken the habit to open a new window when I click on a link. It's the only solution for now.
This bug can be confirmed simply by browing mozilla's extentions and themes library. Click on a theme, then click the back button, and you will always be repositioned back to the top of the page. Not expected behavior.
Back seems to be working for pages that are cached. If pages set nocache/expires etc, the position is not remembered. Of course this bug is probably a LOT more complex than I imagine, but wouldn't a solution be to check if the newly fetched page CAN go to the old position in the document, and do so if it can, or else either go to the top or bottom depending on what people like best? ;) Anyway I'd like to see this bug fixed too as it's pretty annoying. Apart from that: FireFox rock, and so do you developers! :D
There are several duplicates of this bug, in 30 seconds I found: https://bugzilla.mozilla.org/show_bug.cgi?id=47350 (has 19 votes) https://bugzilla.mozilla.org/show_bug.cgi?id=258133 (has 3 votes) Didn't look for more... The former is from 2000-08-02 - This bug is OVER FOUR YEARS OLD?! hehehe I'm amazed :)
*** Bug 287354 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2.0?
In fact, it seems to be a lot better at this time with Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8b4) Gecko/20050811 Firefox/1.0+ Even with bfcache disabled. Probably thanks to bug 47350.
Thomas, what does "a lot better" mean? I'm still seeing the bug.
In fact, I was talking about bugzilla, inter alia. But the bug 215405 is still present. It wouldn't be so visible if webmasters from Apache served sites removed the headers "cache-control: no-store" and "pragma: no-cache" by using the php commands "header("Cache-Control: Public, must-revalidate");". Even with this bug fixed, browsing will still be slower on bad sites (with no-store header), because they force the browser to reload the page even when the back button is clicked.
This is mostly better, but certain cache headers cause us to not store any state information about the page, so there's more core work to do, but this isn't something we can fix in the front end.
Flags: blocking-aviary2? → blocking-aviary2-
...so should this be marked as wontfix, or fixed, or duplicate then?
(In reply to comment #26) > ...so should this be marked as wontfix, or fixed, or duplicate then? This is in the wrong component --> core/history:session
Assignee: firefox → nobody
Component: General → History: Session
Product: Firefox → Core
QA Contact: history.session
Version: unspecified → 1.0 Branch
Version: 1.0 Branch → Trunk
see also: Bugzilla Bug 258133
Flags: blocking-firefox2-
*** Bug 257260 has been marked as a duplicate of this bug. ***
Here is another example http://www.heise.de/newsticker/ (German IT news page) Click on one of the article links, select browser.back => top of page displayed Site is disk cached, but sets "expires" using <meta http-equiv="expires" content="900"> Site uses quirks mode (no DOCTYPE) User agent used for testing: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2 Expected behavior: Invoking browser.back selects link that directed user to other page. Scroll position is updated so that link is displayed.
This site http://www.alexa.com/site/ds/top_sites?cc=US&ts_mode=country&lang=none also has this issue. When I scroll down, and click a link in the list, then use the back button, the page isn't drawn where I last was, but at the start of the page.
(In reply to comment #31) > This site > http://www.alexa.com/site/ds/top_sites?cc=US&ts_mode=country&lang=none > also has this issue. This is a different issue. Alexa seems to use some JavaScript that puts the focus on the search input field. I noticed that FF first correctly displays the page at link I clicked (bottom), but upon loading the page completely, the focus is set to the search input field and the page is scrolled to that field. This site also sets / sends no expiration header (at least I don't see one in Page Info).
I'm just a schmuck user, not a developer, but I can confirm this in FF 2.0, unless I'm missing some intentional behavior. I'm noticing that it happens under two conditions: 1) accessibility.browsewithcaret is set to TRUE (or "Always use the cursor keys to navigate within pages" is checked; which also sets the former flag, and 2) You sit on the target page for a while before clicking Back. Do it right away, it works as expected. Wait a minute or so, and I can repro it pretty consistently. Set the flag to FALSE (either in about:config or through clearing the aforementioned checkbox) and the issue goes away. This was confirmed on both Windows XP and Windows 2000 machines.
Ever since upgrading to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 I've had this problem, and it's driving me completely insane.
On a long page on mediawiki I noticed it as well. The problem disappeared after clicking on a menu item, which puts a #tag in the URL. The tag doesn't have to exists. So, for example: In 10 page long URL https://mydomain/mediawiki/index.php/Main_House, scroll down, select a link, hit the back button and the you're back at the top of the page. Now, edit the url to look: https://mydomain/mediawiki/index.php/Main_House#bob (you can literally use bob, it doesn't have to exist), scroll down again, select a link, hit the back button, and voila, now you're back at the link. Hope this helps
Why is this not fixed? It is late 2007. This feature seems to get fixed about every third or fourth iteration, then the new update comes and it doesn't work again. This is one of the most basic functions on a web page. An example is Yahoo news. When selecting a story link, the back button goes all the way back to the top of the home page. Quite annoying when the story you were reading is waaaay down the page, forcing a rescroll down.
I'd like to report that this still affects 3.0b4, which I was just updated to. I notice it especially on http://cm.my.yahoo.com (must have an account), but many other pages have exhibited the same problem.
I'm not sure if this is exactly the same bug, but I'm noticing this problem with the latest release of Firefox 3. Go to "www.osnews.org" Scroll down Click an article title Click back button Page positions at top, not where it was when I clicked the link.
I see it too, using Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.1pre) Gecko/2008062204 GranParadiso/3.0.1pre But I'm sure you meant www.osnews.com.
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
OK - this is the BACK button we're talking about. Years go by and the freakin' back button still does not work in Firefox. 50 votes. I can't read my.yahoo.com with firefox because it cannot remember it's position on the main page after I click on a story and then go back.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
No longer depends on: 215405
You need to log in before you can comment on or make changes to this bug.