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

NEW
Unassigned

Status

()

defect
12 years ago
2 years ago

People

(Reporter: scott, Unassigned)

Tracking

({DevAdvocacy, reproducible, testcase})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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).
Component: History → History: Session
Product: Firefox → Core
QA Contact: history → history.session
I can reproduce with Firefox trunk on Mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Using Back does not restore previous position within absolutely positioned div → Using Back to "Undo" a named-anchor jump does not restore position of in-page scrollbars (e.g. position:absolute, overflow:auto div)
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
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.
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
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)
Version: unspecified → Trunk
Duplicate of this bug: 1182012
Adding the DevAdvocacy keyword, as references to this bug showed up while researching CSS-only parallax approaches.
Keywords: DevAdvocacy
You need to log in before you can comment on or make changes to this bug.