This is default browser behavior when reopening a hash link through the history. We can build something specific to act as a workaround, like storing the scroll position for a given hash in local storage, or making the scroll position part of the hash code.

This should not be the default behavior for at least some browsers, as they normally cache the page state in memory for history navigation ("bfcache"). We should figure out what in MediaViewer (or MediaWiki) breaks bfcache.

https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching
http://stackoverflow.com/questions/1195440/ajax-back-button-and-dom-updates/1195934#1195934

I think the cache is doing what it's supposed to. If you have media viewer open, the page scroll is 0. So at the time you move to another page, that's what the browser remembers and restores.

I.e. the browser can't be aware that media viewer "isn't really the page".

As for storing page location in localStorage, we are building hack upon hack to pretend we have a zoom function. If the current state is not acceptable, instead of further twiddling we should just suck it up and actually build one.

I didn't suggest that we should implement this hack, I'm just listing possibilities for posterity :) I personally think that trying to compensate for the browser's natural behavior isn't the way to go.

(In reply to Gilles Dubuc from comment #3)

I think the cache is doing what it's supposed to. If you have media viewer
open, the page scroll is 0. So at the time you move to another page, that's
what the browser remembers and restores.

MediaViewer stores the scroll position in a JS variable. If bfcache worked properly, upon backnavigation the browser would reload the page with MediaViewer open and the scroll position variable set, and MediaViewer uses that to restore the scroll position on close.

What actually happens is that the page is restored in its initial position, with MediaViewer closed; and the scroll position is reset due to the hash, so by the time MV opens and stores the scroll position it's zeroed out.

On the topic of relying on the browser, I guess then the solution is to close Media Viewer's UI like ninjas onbeforeunload, but without clearing the hash. This way when navigating back, the browser scroll cache kicks in, and the hash makes media viewer open.

Still an ugly hack... albeit a much faster one to implement.

Opened T73868: Support bfcache in MultimediaViewer about the bfcache issue.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Change 560576 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/extensions/MultimediaViewer@master] After closing, browser sometimes scrolls to the top of the page

https://gerrit.wikimedia.org/r/560576

Change 560576 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/extensions/MultimediaViewer@master] Save history position before opening MMV; remove need to restore scroll position; replace javascript-positioning with static css; cleanup html and css.

https://gerrit.wikimedia.org/r/560576

Test wiki created on Patch Demo by Aron Manning using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/b8b692ed0df0cfb694260dfeb7cfaa3f/w/

Test wiki on Patch Demo by Aron Manning using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/b8b692ed0df0cfb694260dfeb7cfaa3f/w/

Change 560576 abandoned by Ladsgroup:

[mediawiki/extensions/MultimediaViewer@master] Save history position before opening MMV; remove need to restore scroll position; replace javascript-positioning with static css; cleanup html and css.

Reason:

The author has been banned indef from our tech spaces and the patch has not been touched for really long time.

https://gerrit.wikimedia.org/r/560576

Not sure why this is "low" priority. This is experienced by and an annoyance of almost everyone who has ever visited Wikipedia on desktop - which is a lot of people. Should be high in my opinion...

@Lectrician1 See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization - thanks.