Marc Bejarano Reporter
	Description • 20 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040603 Firefox/0.8.0+
Build Identifier: 

meta bug to track all the bugs that cause this symptom

Reproducible: Always
Steps to Reproduce:

	Andrew Hagen
	Comment 1 • 20 years ago

Confirming meta bug.

	Jason Bassford
	Comment 2 • 20 years ago

Correcting dependency order for remaining bugs tracked (I'd already correct bug
215405).

A tracking bug depends on all of the bugs it tracks - it doesn't block them. 
Only when the tracked bugs are fixed, can the tracking bug itself be considered
resolved.

Bug 164421, however, does remain as one that this bug actually does block.  (Bug
164421 will not be resolved until this tracking bug is resolved.)

	flatus
	Comment 3 • 20 years ago

This bug, and in particular 217120, really make the browser disfunctional for
people who navigate sites such as eBay. While there is a workaround (using the
center mouse button to open a new tab when getting item data) it is kludgy and slow.

People continuing to use Firefox when this bug affects them have a special
dedication, or a singular dislike of the alternative browser.

	Jerry Baker
	Comment 4 • 20 years ago

Adding another bug. Although it was maked as a duplicate, I wanted to include it
for the sake of completeness.

	Claud
	Comment 5 • 18 years ago

Particularly noticeable in scrolling thru ebay listings. Noticed that in a long list, the minimum return point was about 4 lines lower upon return. As the the scrolling got further down in the list, the return point got greater, as much as a whole screen once. Since I practically make a living trading on ebay, this really slows me down. I have noticed this happening in the last 2 versions of Firefox.

	Marc Bejarano Reporter
	Comment 6 • 18 years ago

claud: what you're reporting may be bug 43114, but if you aren't sure, please file a new bug.  in any case, this tracking bug isn't the place to discuss specific bugs.

if you do file i new bug, let us know here and it will be added to this tracking bug as a blocker.

thanks,
marc

	Worcester12345
	Comment 7 • 17 years ago

of interest:
Bug 378606 – [FIX]Does not return to the scroll position in the page after reload 

	Aaron Leventhal
	Comment 8 • 17 years ago

Not sure if this should be a dupe of bug 36539 or not.

	Marc Bejarano Reporter
	Comment 9 • 17 years ago

aaron: this bug is a meta bug to track bugs that cause scroll position to not be restored correctly.  bug 36539 is accessibility-related and is about remembering where we were so keyboard navigators can pick up where they left off.  they aren't dupes.  i switched this to block bug 36539 instead of vice versa.

	hjoreteg
	Comment 10 • 6 years ago

Is this really still an issue? Seems it still isn't behaving the way other browsers do: 

1. Go here: http://scroll-back-bug.surge.sh/
2. Scroll to bottom click link
3. Click back button

Expected: 

Scrolls back to bottom (this is what Chrome, Safari, and Edge do)

Actual: 

Stays scrolled to top

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 6 years ago

This is a metabug, so commenting here is not that useful. That specific page does `document.body.scrollTop = 0`, though...

	hjoreteg
	Comment 12 • 6 years ago

@bori(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #11)
> This is a metabug, so commenting here is not that useful. That specific page
> does `document.body.scrollTop = 0`, though...

Hey Boris, thanks for responding! So, the thing is that code only runs when the app changes the URL, not when you click "back", you can verify that by putting a breakpoint on that line. It will run when you click the link, but not when you click "back".

Also where should I be commenting? This is behavior is inconsistent between browsers and seems like a problem for PWAs and all single page apps.

	Boris Zbarsky [:bzbarsky]
	Comment 13 • 6 years ago

> Also where should I be commenting?

New bug blocking this one.  Please cc me.