@mejackreed I could use some help debugging this in the current master. Although there may need to be some changes to integrate it with the refactor, I still don't think I have a grasp of how to actually solve the problem from a strategic point of view.
You can reproduce it by clicking on a thumbnail when you are partially scrolled down. The same will happen if you zoom out to overview perspective after navigating to a further down image with next/previous.
The "_zooming" flag is set in the render function, which determines what transition to do. You'll also see the setScrollElementEvents function, which decides when to set and unset flags and style the relevant elements accordingly. This is done with a timeout, and needs to be abstracted much further somehow. Still working on that, but it will be very helpful to know the source of the scroll problem. Controlling the transitions is by far the worst part of the component, since it doesn't exactly jive conceptually with a "stateless" representation (unless you model time explicitly as part of the state, which is what I'm leaning toward).
@mejackreed I could use some help debugging this in the current master. Although there may need to be some changes to integrate it with the refactor, I still don't think I have a grasp of how to actually solve the problem from a strategic point of view.
You can reproduce it by clicking on a thumbnail when you are partially scrolled down. The same will happen if you zoom out to overview perspective after navigating to a further down image with next/previous.
It has to do with the way the scroll position is translated to the images. Every animation frame, the scroll positioned is "synchronised" by panning: https://github.com/aeschylus/iiifManifestLayouts/blob/master/src/main.js#L675-L679
Note in that function that there is an if statement controlling whether the panning is synchronised in detail mode. (here
This interacts with the synchronise zoom function which is called every animation frame.
The "_zooming" flag is set in the render function, which determines what transition to do. You'll also see the setScrollElementEvents function, which decides when to set and unset flags and style the relevant elements accordingly. This is done with a timeout, and needs to be abstracted much further somehow. Still working on that, but it will be very helpful to know the source of the scroll problem. Controlling the transitions is by far the worst part of the component, since it doesn't exactly jive conceptually with a "stateless" representation (unless you model time explicitly as part of the state, which is what I'm leaning toward).