@Ankry Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences

In T296033#7515187, @MusikAnimal wrote:

@Ankry Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences

No. The global preference for toolbar is also disabled.

The problem was reported to me by other users, who also want the toolbar to be disabled as it is highly resource consuming

Ankry, Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences

No. The global preference for toolbar is also disabled.

Well that's a relief (for me). Upon further inspection, this doesn't appear to be related to the work we've recently done around Global Preferences. I can also confirm it appears to be unique to Wikisource, so I don't think it's an issue with preferences in general.

In T296033#7515221, @MusikAnimal wrote:

Ankry, Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences

No. The global preference for toolbar is also disabled.

Well that's a relief (for me). Upon further inspection, this doesn't appear to be related to the work we've recently done around Global Preferences. I can also confirm it appears to be unique to Wikisource, so I don't think it's an issue with preferences in general.

Moreover, it is related only to the Page namespace in Wikisource. In other namespaces everything seems to be OK.
With toolbar on:

It also overrides my version of the old toolbar that I use (2006 toolbar that is gadgetified). The modern toolbar is highly ineffective for the Wikisource work where I am needing my customisation for quick and effective transcription and formatting work. This change is very impactful on productive work, almost to the point of needing to stop the relieve that aggravation.

@MusikAnimal guessing that the code for ProofreadPage, or the hooks for it, should be checked if it is just Page: namespaces

It seems rthat this ProofredPage change may be responsible for unintended loading of wikiEditor:
https://github.com/wikimedia/mediawiki-extensions-ProofreadPage/commit/645dfcc92e5e41490ab724e79f0627aa928ca2ba
Can someone verify this?
Thanks to @PeterBowman for finding this.

Hmm, I'm out of time for tonight but I'm not sure it's then because an instant return from ext.proofreadpage.page.edit.js doesn't fix it, so nothing in that script can be responsible.

( function () {
	return;
	'use strict';

Resetting PRP and Wikisource extensions way back to 0529869 and c3a2e46 respectively doesn't fix it either, as that's way before the last train, so I actually doubt it's directly a change in either extension. Could be a change in core that's triggering something in PRP?

May it be related to moving the zooming tool outside of the "Proofread tools" submenu? It seems to be initialized regardless of the toolbar setting.
People also report that the tool zooming is less granular now (single zooming is much higher than it was previously). But this needs a separate bug.

Change 740087 had a related patch set uploaded (by Inductiveload; author: Inductiveload):

[mediawiki/extensions/ProofreadPage@master] Use the WikiEditor read hook instead of using() the lib

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

Did the zooming and panning functionality work without the toolbar (when we had the older zooming and panning interface)?

Yep it did. Seems like it will again (although without any buttons maybe).

By the way, configuration of zoom speed is already in the patch queue for OSD improvements: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/740133

Change 740087 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Use the WikiEditor ready hook instead of using() the lib

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

Works in production.

@Ankry the whole 1.38.0-wmf.9 train was rolled back, so the new viewer has been completely disabled. The issue will return if/when the -wmf.9 train goes out again.

We should schedule a backport for Monday (there are no windows on Fridays or at weekends), assuming it does.

Change 740563 had a related patch set uploaded (by Inductiveload; author: Inductiveload):

[mediawiki/extensions/ProofreadPage@wmf/1.38.0-wmf.9] Use the WikiEditor ready hook instead of using() the lib

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

not working or the fix not deployed yet?

In T296033#7521036, @Ankry wrote:

not working or not deployed yet?

Latter... The backport window was before wmf.9 was rolled out to wikis today. I guess we should do it in a day or two.

Change 740563 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@wmf/1.38.0-wmf.9] Use the WikiEditor ready hook instead of using() the lib

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

Mentioned in SAL (#wikimedia-operations) [2021-11-22T19:44:29Z] <urbanecm@deploy1002> Synchronized php-1.38.0-wmf.9/extensions/ProofreadPage/: 10b8440069ac71434274462c545c6b2b2c9182d9: Use the WikiEditor ready hook instead of using() the lib (T296033) (duration: 00m 56s)

@Ankry OSD redeployed today along with a backport for this issue in the evening window (the first after the .9 deployment). Could you check and close if OK?

In T296033#7521448, @Inductiveload wrote:

@Ankry OSD redeployed today along with a backport for this issue in the evening window (the first after the .9 deployment). Could you check and close if OK?

Tollbar disabling works. Other issues reporting in progress...