Page MenuHomePhabricator

Zoom and image move commands not loading properly: "Uncaught Error: cannot call methods on prpZoom prior to initialization"
Open, HighPublic


When editing in the Page namespace, most of the times the buttons for Zoom In/Zoom Out/Zoom Reset do not work.
The console says: Uncaught Error: cannot call methods on prpZoom prior to initialization; attempted to call method 'zoomIn'
so it seems the problem is that the methods are not initialized properly on page loading. When this happens, it is also not possible to move the image.

This problem used to happen sporadically in the past, but since 4-5 days it happens very frequently to many users, making it very difficult (and frustrating) to edit pages.

Event Timeline

Candalua created this task.Sep 12 2016, 8:20 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 12 2016, 8:20 AM

The problem seems to be in the final lines of
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.

Aklapper renamed this task from Zoom and image move commands not loading properly to Zoom and image move commands not loading properly: "Uncaught Error: cannot call methods on prpZoom prior to initialization".Sep 12 2016, 10:52 PM
Aklapper triaged this task as High priority.
Ankry added a subscriber: Ankry.Sep 13 2016, 6:26 PM

Editing a random Page (in this case,_%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 is loaded from somewhere, which triggers ReferenceError: jsAlert is not defined for me.

Yann added a comment.Sep 20 2016, 1:36 PM

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

Ankry added a comment.Sep 20 2016, 1:40 PM

I created a test page with some links:

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,
	if ( $editForm === undefined ) {
			$editForm = $( '#editform' );
	if ( $zoomImage === undefined ) {
			$zoomImage = $editForm.find( '.prp-page-image img' );
	mw.loader.using( 'jquery.prpZoom', function () {
			$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

Legoktm closed this task as Resolved.Sep 21 2016, 5:57 AM
Legoktm assigned this task to Tpt.
Legoktm added a subscriber: Legoktm.

@Yann confirmed this was fixed on IRC.

Thibaut120094 added a comment.EditedSep 22 2016, 10:35 PM

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...


Here's what it should look like (notice the scroll bars):
that's a very old screenshot but you get the idea.

Here's what it looks like right now :
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.

Candalua reopened this task as Open.Sep 24 2016, 10:49 AM
Seudo added a subscriber: Seudo.EditedSep 26 2016, 8:19 AM

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.)

Yann added a comment.Sep 26 2016, 9:05 AM

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

No one cares about the horizontal mode apparently :(

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