Page MenuHomePhabricator

Scroll position is not being preserved when navigating back to the article where image once was opened
Closed, ResolvedPublicBUG REPORT

Description

List of steps to reproduce (step by step, including full links if applicable):

  1. Visit https://en.wikipedia.org/wiki/Hofburg
  2. Scroll down a bit
  3. Click on some image (e.g. "The Swiss Gate")
  4. Close the image by clicking on X
  5. Click on some link in the article (make sure you open it in the current tab)
  6. When another article is loaded, hit the back button
  7. And see that the scroll position in the firstly loaded page ("Hofburg") wasn't preserved

What happens?:
Scroll position at the top of the article

What should have happened instead?:
Scroll position should be preserved

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:
macOS Catalina 10.15.6 (19G73), Chrome Version 94.0.4606.61 (Official Build) (x86_64) without any extensions
Looks like this bug occurs only on macOS, I've just checked on Windows position is being preserved normally in that case

Event Timeline

Hi @7dyuhejg7xm0, thanks for taking the time to report this and welcome to Wikimedia Phabricator!
I can confirm this in Chromium - the behavior differs on other websites. This seems to only happen after opening MediaViewer.

T296149 that I created documented a similar bug except my task was about on-page navigation using the table of contents. But by all appearances they have the same root issue. So, both on-page navigation with "Back" and "Forward" and keeping the scroll position in the case of cross-page navigation are impaired.

Note also that this is not just a Chromium problem – Firefox is affected as well. (I checked the list of steps for this task as well and could reproduce in Firefox.)

Aklapper triaged this task as Low priority.Jul 14 2022, 9:51 AM
matmarex changed the task status from Open to Stalled.May 25 2023, 10:05 PM
matmarex subscribed.

I can't reproduce this today. Likely this is caused by some behavior changes in the browsers, rather than in our code. Can anyone still reproduce the issue? And on which browsers?

Hey @matmarex! Yes, looks like issue is fixed. Thank you!

Closing per last comment