An alternative is the common idiom Ctrl-scroll to zoom and scroll-to-pan (and Shift-Scroll to pan sideways) which is the system used by GIMP, Inkscape and Firefox.

Please keep away from two handed actions (mouse + keyboard) whenever possible.

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

[mediawiki/extensions/ProofreadPage@master] OSD: Add Ctrl and Shift scroll actions

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

The current state of the scroll/pan is:

• Click and drag: pan the image
• Scroll wheel: zoom the image in and out
• Ctrl+scroll: pan the image up and down
• Shift+scroll: pan the image side to side
• Left click: zoom in one step
• Shift-left click: zoom out one step

The middle mouse button switches the normal and Ctrl-key modes (so Ctrl-scroll becomes zoom and normal scroll becomes pan). The cursor changes to identify which mode you are in.

Outstanding questions, assuming we keep this approximate system:

• Middle button or left button to switch scroll/pan modes? While left button did, kind of, work for this at WS in the old viewer, it's different to basically every other image viewer in the world, and not only the OSD-based ones.
• Should we:
  • add a config option to start in scroll mode rather than zoom mode
  • make it persistent (so it sticks across page loads)
  • Do nothing and just start in zoom mode on every page load (this is what happens now, not by special intent, just by lack of specification and implementation).
  • Do nothing but flip the starting mode to scroll (same as it used to be?) but different to every other viewer in the world

@Inductiveload, none of the above suggestions scroll the content. Were there any problems with the previous arrangement? If not, these changes may entertain and occupy the developers, but don't nothing to help editors. Please don't break something that works. Can I disable the magnifier on the pages I want to work and get back scrolling until this is sorted out and functioning?

@Ineuw there were major technical problems with the old implementation. I didn't implement this change, but I can tell you that it wasn't done for fun, entertainment or or to "occupy" a developer. In fact "occupying" a developer is the last problem we have since we are as critically short of development resources as ever.

Three out of four of the above suggestions (1, 2 and 4) would functionally allow you to scroll the image by default instead of zoom. Do you have a specific preference for which would be best and why? Have you tried a patch demo (the current one is https://patchdemo.wmflabs.org/wikis/09e7300254/wiki/Main_Page and includes a re-implementation of the old click-to-toggle behavior, with middle-click)?

If the patch demo works for you, it is in theory possible to backport to common.js, since the new system gives fully flexibility to userscripts to set the viewer options.

@Inductiveload, I am not blind to the shortage of developers, but from my viewpoint, I am also aware that Wikipedia offers an excellent opportunity for honing and refining programming skills.

Lowly proofreaders like myself are unable to keep up with the changes in software development and advancement of past the two years. All I am asking is that the implementation of new ideas should take a more cautious approach. It is possible that these upcoming changes were mentioned in the bulletins, which I didn't read to focus on proofreading. It is also true that for me it's about losing valuable leisure time, so please accept my apology, and explain how to to link into the "patchdemo" through my Wikisource vector.js. Thanks

You cannot link into the patchdemo as that's on a completely different infrastructure. However, if you answer the question "does the patchdemo approach work for you?" then that code can be backported to user js. Without that answer, I can't tell if you think the patchdemo approach is good, bad, useless or what.

And if you have a preference for any of the 4 further options, that can be done too (except #1, which needs a server option, and #3 which doesn't need a further change). But you actually do need to say it for anyone to know which you prefer.

The answers are also fairly important in general, as they will allow us to add to or change the system, since the patch demo approach will, eventually, be merged. It could be weeks or months at the current rate of review, but one day it will hopefully land.

Thanks for the reply. As far as I understand the information in 'patchdemo' is that the order of mouse scroll behaviour would be:

1 Scroll
2 click to Zoom
3 Ctrl-scroll: pan up/down
4 Shift-scroll: pan side-to-side

This would be my order of preference as well. The user has to observe the pointer for the current status. Am I correct?

No, that's not quite right. The default scroll action is zoom. Have you actually tried the patch demo?

And yes, the user has to look at the cursor for the current mode. This is a change, as before there was zero indication to the user about what would happen if they scrolled as the cursor was always the same. This, plus the finicky click handling led to quite some confusion.

As always, if you have a better idea, please let us know!

@Inductiveload, I apologize for the delayed reply. I get no emails from this site, even though it's properly configured.

There is no patch demo page now to test it. In any case if it was supposed to work on Wikisource, it isn't. It's the same as before. No scrolling.

The patch demo is linked above and its still there. This isn't merged yet so it will rather obviously not be on Wikisource.

Are you referring to this link on the patch demo? because it's no longer exists for testing [[Page:Shen_of_the_Sea.pdf/45]]

It doesn't need to exist to edit the page. A red link always takes you directly to the edit form. All you have to do is click on it.

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

[mediawiki/extensions/ProofreadPage@master] OSD: Persist scroll action setting across reloads

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

"It doesn't need to exist to edit the page. A red link always takes you directly to the edit form. All you have to do is click on it."

Some users don't live in your head.

Thanks. I got it working and it's scrollable. Just to point out that the demo over/under or side by side is not working properly,

I have, with not a small effort, rebased the outstanding OSD patch stack (again) to put this change at the front. I have no further interest in shepherding this issue. Someone else can take point on this to get it merged.

The image scroll feature doesn't exist. Is there a plan to revive it?

Is there a chance for the image scrolling to be restored?

Loss of mouse scrolling is a major problem right now, specially for big books with small fonts, where lots of zooming in/out and scrolling is needed.