1681977 - Closing photo view in Wikipedia does not restore the scroll position

Status: RESOLVED DUPLICATE of bug 1594345

(External Software Affecting Firefox :: Other, defect, P3)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

0. Turn on Fission
1. Open https://ko.wikipedia.org/wiki/%ED%8F%AC%ED%95%AD%EC%8B%9C#%EB%AC%B8%ED%99%94%C2%B7%EA%B4%80%EA%B4%91
2. Click any photo
3. Close the view

Expected: The previous scroll position should be restored
Actual: It's now at the top position

Comment 1

[Chris Peterson [:cpeterson]]

Olli thinks this is a Wikipedia bug related to a script timeout and async back navigation taking longer with session history in parent.

Wikipedia has a patch in https://phabricator.wikimedia.org/T229484 for bug 1594345, but it hasn't landed yet.

I can reproduce this bug with session history in parent (fission.sessionHistoryInParent pref), with or without Fission. Tracking for Fission M7 Beta milestone. We'd like to ship session history in parent before we ship Fission.

We should reach out to Wikipedia folks again, but Olli will debug the Wikipedia code first.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

FWIW, I've contacted wikipedia folks. This issue happens rarely without Fission too and also in other browsers.

Comment 3

[Neha Kochar [:neha]]

This needs Wikipedia fix, and we haven't had any luck in them fixing it. Pushing this out to Fission M8 since this is not actionable for us yet.

Comment 5

[Neha Kochar [:neha]]

This needs a fix from Wikipedia that's being tracked in bug 1594345

Comment 6

[Demian]

(In reply to Neha Kochar [:neha] from comment #5)

This needs a fix from Wikipedia that's being tracked in bug 1594345

Exactly. The bug is caused by mediawiki removing the page content from the layout, thus reducing the page height to 100vh and scrollPos to zero before Firefox (or Chrome for that matter) saves the scroll position. After history.back() both the MediaWiki and the browser restore the saved position asynchronously, resulting in a race condition between the correct and zero scroll position.

This can be solved by disabling history.scrollRestoration or by replacing the unnecessary DOM manipulation with a properly designed modal layout for the image viewer. The latter has been done and submitted by Feb 2020, but Wikimedia's developers have shown no interest for the fix:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/560576

The fact that this bug still exists along with the inefficient design of the image viewer is solely the responsibility of the WMF, as the solution was there for more than a year. Unfortunately, open-source contributions are seldom considered, as in-house solutions are preferred, but the necessary manpower and skills are not often available.

Comment 7

[Neha Kochar [:neha]]

Moving to Fission MVP just for tracking Fission open issues but there is no Firefox fix expected or needed for this.

Comment 8

[Chris Peterson [:cpeterson]]

Closing this bug as a duplicate of webcompat bug 1594345. This is not a Fission bug, though Fission's timing changes might make it more frequent.

As Demian mentioned in comment 6, fixes for Wikipedia's bug have been submitted, but Wikimedia developers haven't landed any of them yet. Once we ship Fission in Firefox, Wikipedia might be more likely to fix their bug.