Open dmolesUC opened 3 years ago
The best way to do this with a Mirador 3 plugin is to use a custom Redux Saga that reacts to a Redux action. In your case, a good choice would be to wait for the ADD_WINDOW
action and then add your event listener to the window's OSD instance:
// untested, just for illustration purposes
function* disableMouseWheel(action) {
// TODO: You'll have to determine the OSD element for the new window from the
// action's payload somehow, I recommend using a debugger to inspect it
// and some M3 source code digging for context.
// If you only need to deal with single-window sessions, you can just
// reuse your selector
const osdCanvas = null /* TODO */;
osdCanvas.addEventListener(
'wheel',
(evt) => { evt.stopPropagation() },
{capture: true}
);
}
function* rootSaga() {
yield takeEvery(ActionTypes.ADD_WINDOW, disableMouseWheel);
}
// In your plugin definition, add a `saga` key that has the above root
// saga as its value
but while this stopped the scroll wheel from zooming, it didn't free it up for scrolling the browser window.
@dmolesUC : can you tell if OSD is still capturing those events, or is it something else in the stack? If it's OSD, I wonder if they'd consider that a bug
@jbaiter The thing is, I'm not writing a plugin, I’m just trying to embed Mirador in a Rails app. (Cf. the “Deployment contexts” discussion in #1693.)
@cbeer Good idea. I'll see if I can put together a self-contained case to reproduce it, when I get a chance, and try filing it there.
Responding to the initial issue mentioned, i.e. there not being an option to disable zoom on scroll. There are various configuration options for pointer events in OSD, see the GestureSettings
To disable zoom on scroll set:
osdConfig: {
gestureSettingsMouse: {
scrollToZoom: false
}
}
Much cleaner than a plugin indeed, thank you for the update!
Looking for a way to disable mouse scroll-wheel zoom (we're using Mirador as a viewer for scanned text pages, and when you're viewing a portrait page on a landscape laptop screen, the scroll wheel's much more useful for scrolling the browser window up/down than it is for zooming), and not finding anything in the settings, I first tried
but while this stopped the scroll wheel from zooming, it didn't free it up for scrolling the browser window.
The next hack I came up with was this:
However, while it worked if I entered it in the browser console, it didn't work in the window load handler immediately after initializing the Mirador viewer — I assume because the OSD DOM elements didn't exist yet.
I read through #1693 and the state management wiki page. The state managment docs say:
— but, me not being a Redux programmer (I've done a little programming in this pattern with the now-defunct ReduxFX several years ago, so I understand the paradigm conceptually, but that's it) it wasn't immediately obvious how to do that, and even less obvious how to de-inject my reducer after it's done its one-time job of adding a listener to prevent wheel events from reaching OSD. (Plus I'd have to figure out which action is liable to be called after OSD is loaded, but I imagine I could do that with trial and error.)
After reading some Redux docs, I came up with this:
It works, but it strikes me as pretty ghastly, and a bit of an abuse of Redux' Store.subscribe(), since I don't actually care about the state of the store, I'm just generally assuming there's likely to be a store stage change not long after OSD is loaded, and probably before the user has much chance to fiddle with the scroll wheel.
Is there a cleaner way?
(I'd like to second #1693's call for “my containing page to receive notice when things in the viewer change” — this sort of hackery definitely seemed easier with Mirador 2 events. 🙃)