The problem seems to be in the final lines of https://phabricator.wikimedia.org/diffusion/EPRP/browse/master/modules/page/ext.proofreadpage.page.edit.js
It looks like $(window).load() for some reason is not firing. I am not sure how to fix it though.

Not a problem that I am having — Firefox 48.0.2, using monobook skin, old toolbar

Obviusly vector skin must run too.... we can't migrate to the old monobook skin just to avoid a recently introduced bug.

I'd like a "stable" version of mediawiki, problems with new versions are too frequent in the last years. New versions should be much more deeply tested into all projects (first of all into wikisource, that's particularly complex) before implementation.

Issue mentioned here: https://fr.wikisource.org/wiki/Wikisource:Scriptorium/Septembre_2016#Aide_.C3.A0_la_relecture

Editing a random Page (in this case https://fr.wikisource.org/w/index.php?title=Page:Diderot_-_%C5%92uvres_compl%C3%A8tes,_%C3%A9d._Ass%C3%A9zat,_III.djvu/454&action=edit&debug=true ) in Vector skin and Firefox 48, I don't get any bottons for zooming at all (using my mouse / touchpad works though in order to zoom), and no output in the console.

Dropping the &debug=true from the URL, I get some output in the browser's developer tools:

This page is using the deprecated ResourceLoader module "jquery.ui.widget".
This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead.
This page is using the deprecated ResourceLoader module "jquery.ui.position".

And likely unrelated, but after enabling some gadgets on fr.wikisource, I get some errors which should get fixed:

MediaWiki:Gadget-annotator.js - TypeError: jQuery.sub is not a function

It also seems that https://pl.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=Wikipedysta%3ANux%2FSearchBox.js is loaded from somewhere, which triggers ReferenceError: jsAlert is not defined for me.

For me, it works with Firefox, but it doesn't work with Chrome, IE, Edge. Tested on Win7 and Win10.

I created a test page with some links:

https://pl.wikisource.org/wiki/Wikiskryba:Ankry/brudnopis8

The upper links loads pages with debbugging enabled.
The bottom links are with no debugging.

When I open the links randomly using "open link in a new tab" and I do not make the new tab active until the page finishes loading:

• the pages with &debug=true are loaded properly (image moving/rescalling works fine)
• on all pages without debugging, the image moving & rescalling do not work.

Tested as anonymous user on various browsers (opera/FF/chrome).

So enabling debugging hides this problem totally.

If the tab with the page being loaded is active the effect appears randomly. Unsure what id depends on (browser used, cache usage, language settings, time of the day, etc.). Sometimes all pages load fine; sometimes none.

I also noticed that when I switch tabs, the pages with debugging anagled are showed immediately in browser. The pages (with non-working zoom) without degugging are showed with a slight delay. Like some scripts being delayed and starting after the tab becomes active. Unsure what is the reason. (I did not observe this effect few months ago with the same browser.)

If some scripts are really deleyed, maybe it disturbs the expected loading sequence?

BTW, because of this problem I am using this ugly hack (thanks to Zdzislaw) in my common.js:

$( function ()  {
	if ( mw.config.get( 'wgPageContentModel' ) !== 'proofread-page' ||
	$.inArray( mw.config.get( 'wgAction' ), [ 'edit', 'submit' ] ) === -1
		) return;
	var $zoomImage,
		$editForm;
	if ( $editForm === undefined ) {
			$editForm = $( '#editform' );
		}
	if ( $zoomImage === undefined ) {
			$zoomImage = $editForm.find( '.prp-page-image img' );
		}
	mw.loader.using( 'jquery.prpZoom', function () {
			$zoomImage.prpZoom();
			$zoomImage.prpZoom( 'reset' );
		} );
} );

This helps a bit, but not always works as expected (sometimes does not work at all; in some browser images loaded this way are not scalled properly).

Happy to know that it.wikisource isn't the only project with the listed issues. We are notified about new mediawiki versions, but probably we should be notified soon about new versions issues.... just to avoid to waste time to debug our scripts, while issues come from known, general problems.

As I told before, a "stable" version of mediawiki is needed for daily work, and new versions should be much more carefully, and deeply tested before installation. I'm feel very unconfortable when I see a mediawiki alert about a new mediawiki version....

Change 311743 had a related patch set uploaded (by Tpt):
Makes sure that the zoom widget is initialized before zooming in/out

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

Well there's now another problem, if I'm in horizontal mode, double-clicking on a word won't move the page to the text line.

Dunno if I'm clear, but I really can't proofread text like this...

EDIT :

Here's what it should look like (notice the scroll bars): https://commons.wikimedia.org/wiki/File:01_Open_header_and_original_text.jpg
that's a very old screenshot but you get the idea.

Here's what it looks like right now : https://i.imgur.com/1Bu5nLr.png
The entire page is displayed instead of just a part of the page.

I think the patch broke something so I don't know if I should open a new ticket or reopen this one.

EDIT 2: See T145923

EDIT 3: Fixed (finally)

While now the zoom buttons always work for me (thank you @Tpt!), I noticed that sometimes it is still not possible to move the image. When this happens, clicking on one of the zoom buttons makes the image moveable again.

I confirm what Candalua says. More precisely, zooming using the mouse and moving the image do not work when I load the page. But after I click on the zoom button once, zooming and moving with the mouse work.

(On another computer, zooming and moving the image with the mouse always work.)

I also confirm what Candalua and Seudo say. It happens quite randomly for me.

No one cares about the horizontal mode apparently :(

In T145365#2666475, @Thibaut120094 wrote:

No one cares about the horizontal mode apparently :(

Not sure what you mean by that, however since this change was deployed it seems also that when you switch to horizontal mode, the height is not correctly set; so the image becomes extremely big.

Dealing with more difficult texts (ancient & with small font/faulty images) some of out best and more careful reviewers use horizontal view by default. Previously running editing interface must be restored as soon as possible.

This task also covers the problem with the overly-large image in over-under display mode: T145923: Need to reduce nsPage body edit box height in horizontal view