User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20170608175746 Steps to reproduce: - Visite a dynamic site - Scroll down reading it - Click into the address bar and press enter to load it again (F5 always preserved the scroll position, loading it again via address bar did not) Actual results: The page is reloaded with the same scroll position, while the content changed Expected results: Like before, the scroll position should be reset to 0 when a page is loaded. Preserving it on usual refresh may or may not be useful, but when loading it (again) from url bar it should be like on the first visit.
Component: Untriaged → Document Navigation
Product: Firefox → Core
When I used F5 to refresh, I got the same result as what reporter got. And in my opinion that is expected as F5 refreshes the page but it uses cached files, per . If I used CTR+F5 or simply click the url bar to refresh, the scroll position is reset as expected. Nightly 56 and 46 behaves the same, and both worked well. Hi Alex, looks like you were using an old version (FF49). Could you please use the latest version and try again? Thanks.  https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_navigation
I can reproduce with firefox 54. I am not even sure, if it happens with 49, i reported the bug on another PC than i tested with. I think it changed around version 50. One question is, what actually is the intended behaviour? I understood the Enter in the address bar as being like loading another page, so it starts at scroll position 0, while F5 without ctrl (btw. do you mean shift like in ctrl-shift-R?) preserved the position. You may discuss, if preserving the position on a page with a lot of change is useful at all, but that's probably out of the scope of this bug. A possibly related bug: Often when navigating to a new page via url bar, it loads and still displays still the old page. After pressing enter the second time it loads again, shortly displays a blank page (probably as it should) and then shows the new (or changed) page. This one may be more recent than the refresh behaviour and is harder to reproduce. > And in my opinion that is expected as F5 refreshes the page but it uses cached files, per . I think refresh via ctrl-r (I do not know how consistent it is with F5) should reload the page using expires and if-not-changed headers, which may or may not result in a changed page (which possibly should reset the scroll position), while ctrl-shift-r always refreshes all resources.
I think Anne may know what's supposed to happen here but if not, we should ask Gijs.
I think what happened before: - Enter: (Re)load page, with cached resources, especially images, css, etc. Good to refresh content without unneccessary refresh of images and so on. - Ctrl-R: Revalidate all resources (if-modified-since header, etc.) - Ctrl-Shift-R: Reload all resources (no-cache header)
Yeah, Gijs might be able to help or know someone from UX. Ultimately this should be a design decision. (Per the specification scroll position is just another bit of information on a history entry, but it doesn't really say how the UX should be.)
Flags: needinfo?(annevk) → needinfo?(gijskruitbosch+bugs)
(In reply to Anne (:annevk) from comment #5) > Yeah, Gijs might be able to help or know someone from UX. Ultimately this > should be a design decision. 302 Philipp about whether we need / want to reset the scroll position when loading a page by pressing enter in the location bar (keeping the scroll position when using refresh / f5 as we do now seems uncontroversial).
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(philipp)
Yep! This makes sense! FWIW, Edge has this behavior today.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Loading a page again falsely preserves the scroll position → Reloading a page by pressing enter/return in the URL bar should not preserve the scroll position
I had the same problem when navigating from a website (in an intranet, so i cannot link it) to another page with a normal hyperlink. Is there some heuristik in the behaviour for saving the scroll position, possibly like having the some of the anchor tags in the page on the next page as well or something similiar?
For the F5 behaviour: Vivaldi (Blink engine) does preserve the scroll position on reload (F5 or ctrl-r) as well, even when the page content is completely different. Seems like this is kind of expected behaviour.
You need to log in before you can comment on or make changes to this bug.