1594345 - Close the Wikipedia's Image Viewer does jump page to top

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P3)

Description

[breakmt]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

1. Open web page with pictures which you can open in same page (example, wikipedia https://en.wikipedia.org/wiki/Musical_notation),
2. Scroll to the middle of the page,
3. Open picture,
4. Close picture

Actual results:

Focus jumps to page's top

Expected results:

Same place as step 2

Comment 1

[YF (Yang)]

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f7dd2503e50989bd39121a7a2be4fd48d83ee12c&tochange=214fac6eb1c05177c7ef8eb29b87cceb09eb4110

Comment 2

[Kohei Yoshino]

Updated the site compatibility note to mention this bug.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Recent regression, too late to fix in 70 but we could still take a patch in 72.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Olli can you take a look? Thanks!

Comment 5

[Pascal Chevrel:pascalc]

Neha, could you help us prioritizing this bug and finding an owner of it needs a fix in the 71/72 time frame ? Thanks

Comment 6

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

FWIW, it isn't clear that this is a Gecko bug. It could very well be that the website has some Firefox specific code, and now that we behave like other browsers, the behavior is broken. But I'm planning to look at this this week.

Comment 7

[Kohei Yoshino]

This is a tech evangelism bug. A quick research finds:

• this.router.back() is a deferred.promise() but there’s no then(), so it’s not async-ready
• Then there is a setTimeout() hack for Chrome but it’s not working for Firefox probably because the delay is not specified

Comment 8

[Alice0775 White]

Workaround:
user_pref("dom.window.history.async", false);

Comment 11

[Pascal Chevrel:pascalc]

Marking as wontfix for 71 as this seems to be a webcompat bug. Mike, do we have contacts at Wikipedia or a bug tracker where we could report this issue?

Comment 12

[Pascal Chevrel:pascalc]

Nevermind, I see that a patch is in the pipe on the 'see also' link.

Comment 13

[Andre Klapper]

(In reply to Pascal Chevrel:pascalc from comment #12)

Nevermind, I see that a patch is in the pipe on the 'see also' link.

I don't see a patch there - could you provide an explicit link?

Comment 14

[Neha Kochar [:neha]]

Removing my NI as this is a tech evangelism bug.

Comment 15

[Kohei Yoshino]

So looks like Wikipedia folks are trying to fix the issue by adding a 50ms delay to the setTimeout() hack mentioned in Comment 7. Not the best solution but a minimum effort.

Comment 17

[Kohei Yoshino]

Moving to a proper component given a site-specific issue.

Comment 18

[Dan]

(In reply to Kohei Yoshino [:kohei] from comment #15)

So looks like Wikipedia folks are trying to fix the issue by adding a 50ms delay to the setTimeout() hack mentioned in Comment 7. Not the best solution but a minimum effort.

20 days later, still neither a Wikipedia fix nor FF fix? :/ (I'm running FF Dev edition, still affected). What means "fix-optional" ? Couldn't find a description on wiki.mozilla.

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Hi Daniel. It looks like Wikipedia may have a fix coming (see https://phabricator.wikimedia.org/T229484; a patch is waiting for review).

I marked this bug "fix-optional" for Firefox 72 and 73, because the fix is coming from Wikipedia, not in Firefox so there is no work to be done in this bug by our developers. I'm keeping this bug open, though, so we have a chance to follow up to make sure the fix works. I'll try commenting in the Wikimedia issue.

Comment 20

[Kohei Yoshino]

Somehow I can no longer reproduce the issue, though the patch is still under development by Wikimedia folks.

Comment 21

[Seba S.]

Hi,

I've re-tested this on the latest nightly 82.0a1 (2020-08-27) and Firefox 81.0b3, and both versions are unaffected. I don't know if I should close it, I'll leave the update FYI.

Regards,

Comment 22

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

wikipedia seems to have been fixed. (This was a site issue)

Comment 23

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

Given bug 1681977, I guess this still happens every now and then. And https://phabricator.wikimedia.org/T229484 hasn't been fixed.

Comment 24

[Demian]

As detailed in https://bugzilla.mozilla.org/show_bug.cgi?id=1681977#c6 this issue is caused by MediaWiki indirectly setting scrollPos to zero before the browser saves the scroll position, but keeps history.scrollRestoration enabled, which in turn restores the 0 scrollPos. MediaWiki also restores the correct scrollPos, but the order of the two is undefined behavior, resulting in this race condition.
A solution was ready by Feb 2020, but never reviewed. The issue is within MediaWiki, Mozilla cannot do anything to fix it.

Comment 26

[Karl Dubost💡 :karlcow]

OK and this has been fixed on wikimedia side!
https://phabricator.wikimedia.org/T229484#7265596