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

Status: NEW

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

Description

[Lubos Kosco]

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

Comment 1

[Lubos Kosco]

Attachment: ziped page which is used to reproducing the problem

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, and there's no layout history state in the shentry here.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fixing issues with restoring subframes might be part of the work I plan (sometime, I hope) in bug 43114, although not necessarily.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: This does work to fix the bug, but is all sorts of inefficient and hacky

Comment 7

[Lubos Kosco]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 10

[marshallx7a+ff]

Has this issue been dead for 4 years? The bug is still there and it is a major headache.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

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

Comment 12

[Alin Ilea, Desktop Test Engineering]

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