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
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
then URL changes, but content will not scroll to old anchor :(
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
Created attachment 444618 [details]
ziped page which is used to reproducing the problem
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.
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.
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.
Created attachment 444837 [details] [diff] [review]
This does work to fix the bug, but is all sorts of inefficient and hacky
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)?
> 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.
*** Bug 597987 has been marked as a duplicate of this bug. ***
Has this issue been dead for 4 years? The bug is still there and it is a major headache.