Open Bug 565008 Opened 14 years ago Updated 2 years ago

back button doesn't take you to original anchor (even though url changes) - "css frames" are used

Categories

(Core :: DOM: Navigation, defect, P3)

x86
All
defect

Tracking

()

People

(Reporter: tarzanek, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4) Gecko/20100407 MozillaDeveloperPreview/3.7a4 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a4) Gecko/20100407 MozillaDeveloperPreview/3.7a4 ( .NET CLR 3.5.30729)

attached a zip file with a sample html+css combination
- click on numbers on left side (scroll down a page and click on new ones) and press back button - it will not take you(scroll to) to original anchor

fwiw Chrome and Safari work here, so I think this is a prob with the engine

Reproducible: Always

Steps to Reproduce:
1. unzip attached page
2. open it in any firefox/mozilla browser
3. click on a line # on left side
4. scroll down a page or two
5. click on new line # anchor
6. press BACK button


Actual Results:  
then URL changes, but content will not scroll to old anchor :(

Expected Results:  
URL changes, you will scroll to old anchor and be happy :)

Chrome and Safari back buttons work properly with the same page and navigate(scroll) you to proper anchor
OS: Windows Vista → All
The problem is that on history navigation people don't actually want to go back to the anchor they had loaded when they first loaded that page; they want to go back to wherever in the document they were.  So on history navigation we restore the scroll position we used to be at.  The problem is that we only do this for the toplevel scrollbars on the page (which this page suppresses) and we don't perform anchor scrolls at all on history loads.
Status: UNCONFIRMED → NEW
Component: Layout → Document Navigation
Ever confirmed: true
QA Contact: layout → docshell
Oh, and there's no layout history state in the shentry here.
Fixing issues with restoring subframes might be part of the work I plan (sometime, I hope) in bug 43114, although not necessarily.
Depends on: 43114
This isn't a subframe.  It's just an abs pos overflow:auto div (with the body set to overflow:hidden).

One obvious option here is to perform the anchor scroll on history load before restoring the toplevel scrollbar.  That would give us behavior similar to webkit on this testcase.  Better would be to properly restore scroll state, of course.
cool, nice to see people working this out ;)
will this be able to propagate to some near future firefox release ? 
(if yes, then which release ?)
if no, what can I do to make firefox adopt this fix(file a bug against them too)?

thnx
L
> will this be able to propagate to some near future firefox release ? 

Not in the state I attached. It'd need a good bit of work to be ok to check in.

If something gets checked in for this bug, the next non-branch Firefox release would pick it up automatically.
Priority: -- → P2
Has this issue been dead for 4 years? The bug is still there and it is a major headache.
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3

Still reproducible in latest Nightly 95.0a1 (2021-11-01).

Severity: major → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: