391664 - Using Back to "Undo" a named-anchor jump does not restore position of in-page scrollbars (e.g. position:absolute, overflow:auto div)

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Scott Eade]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

I have a page with some content presented in an absolutely positioned div that has overflow set to automatic (so a scroll bar appears when too much content is added).  If the content includes a link that jumps to further down the page, the link works fine, but the scroll position is not restored when the Back button is used.

Reproducible: Always

Steps to Reproduce:
1. Load a page containing the attached html
2. Click the Bottom link
3. Click the Back button
Actual Results:  
The scrolling within the absolutely positioned div does not change when Back is clicked.

Expected Results:  
The previous scroll position should be restored.

Opera exhibits the same problem (though I don't have very latest version installed) but IE7 does.  I don't mean to come off as a "it works this way in IE7, Ff should be the same" - I am actually looking into a problem with ExtJS 1.1 that is somewhat related (see: http://extjs.com/forum/showthread.php?t=10825).

Comment 1

[Scott Eade]

Attachment: Example page that demonstrates the problem

Comment 2

[Jesse Ruderman]

I can reproduce with Firefox trunk on Mac.

Comment 3

[Pablo Rauzy]

Hi! This bug is still present in firefox "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.19) Gecko/20110430 Iceweasel/3.5.19 (like Firefox/3.5.19)".

It's kind of an important bug IMO.

Comment 4

[Justin Lebar (not reading bugmail)]

Pablo, it looks like you're using a very old version of Firefox.  You may want to upgrade to Firefox 4.

In any case, I can reproduce with trunk.

Comment 5

[Justin Lebar (not reading bugmail)]

I just tested the latest versions of Chrome and Safari and also IE9 on Windows 7.  Each of them behaves the same as FF4.

This doesn't seem worth fixing at the cost of compatibility, to me.

If it's really important that your page scroll like this, you can listen to the hashcahnge event and scroll the page using javascript.

Comment 6

[Pablo Rauzy]

@Justin: I'm using Debian testing and it's the version of firefox in the repos.

Chromium behave as I was expecting on my computer (the bug is not here) as well as Midori (another webkit-based browser). A friend told me that it also works in Safari. I don't know for IE and Opera. But to me the compatility issue is when the bug is here.

I was trying to avoid javascript but maybe I could add a bit of javascript just for this... However it would be nice if this bug was fixed :-)!

Comment 7

[Justin Lebar (not reading bugmail)]

Yes, Debian is a bit...slow.  But we're just about to drop support entirely for FF 3.5, so we're not really concerned with test results from that version.  Debian needs to get its act together (and presumably they will once we say that we're not shipping security updates for 3.5 any longer).

I can't reproduce behavior than FF4 on Mac or Win7 in Chrome 11 or Safari 5.  Maybe you have a different version of Chromium?  I'd also encourage you to download the FF4 binary from http://getfirefox.com and test with that.

Comment 8

[Pablo Rauzy]

I've just tried with the ff4 from getfirefox.com and it's even worse: the urlbar does not change at all and I can't use previous/next button (they stay blurred)... But it's a general problem, it's not just for anchors. FF4 doesn't seem to be really usable for now!

Comment 9

[Justin Lebar (not reading bugmail)]

Pablo, try the Debian Mozillateam's builds?  The back button should work...

http://mozilla.debian.net/

Comment 10

[Pablo Rauzy]

I'll may do that later but I really don't need to have ff4 right now. Anyway thanks for your time :-).

Comment 11

[Gavin Kistner]

This bug is still present in FF v13 (and Opera v11, and IE v9); the behavior works as expected in Chrome v20 and Safari v5.

Online test case:
http://phrogz.net/tmp/backing-into-subpage-anchors-in-overflowed-containers.html

Further discussion:
http://stackoverflow.com/questions/10918242/backing-into-subpage-anchors-in-overflowed-content

Comment 12

[Nickolay_Ponomarev]

Attachment: testcase #2 - two different anchors

I've attached testcase from comment 11 (thanks Gavin!) here so it doesn't get lost.

There are two related cases, in which Chrome (at least) behaves differently:
1. Back/forward from an anchor to no anchor: Chrome behaves the same as Firefox (doesn't scroll the overflowed element). This is what the original comment 0 is about.
2. Back/forward between anchors: here Chrome scrolls, but we don't.

STR where we behave differently from Chrome:
1. Load the attached testcase.
2. Click Section B
3. Click Section C
4. Click back (Chrome scrolls back to Section B, Firefox stays at Section C)

Comment 14

[Dietrich Ayala (:dietrich)]

Adding the DevAdvocacy keyword, as references to this bug showed up while researching CSS-only parallax approaches.