Contain outside prevents movement when panzoom element is smaller than parent.

[icithis]

Describe the bug

When contain is set to outside and the panzoom element has smaller dimensions than the parent, the panzoom element is moved to the bottom right corner and cannot be panned.

Your environment

• Version of panzoom - 4.4.1
• Browser and browser version - Chrome 93.0.4577.82

Expected behavior

I expect to be able to move the element inside of the parent.

Actual behavior

I can't move it at all.

Steps to reproduce

Take the example of the contain outside in the demo and resize the panzoom element to 150px x 150px.

https://jsbin.com/powibebaqo/edit?html,js,output

[icithis]

To add to this, I have a dynamic element which resizes based on the user's interaction. Sometimes it is larger than the parent, sometimes it is smaller. So, in my use case, the parent is always 1000px x 500px, and the child ranges from 25% of that size to 2500% of that size.

[timmywil]

contain: outside is documented to only work when the Panzoom element is larger than the parent. However, an earlier version of Panzoom had a special value for contain that would swap between contain: 'outside' and contain: 'inside' depending on the size of the Panzoom element. Would that suit your needs here? If so, I think we can call this a feature request.

[icithis]

The only concern I have with that feature is that it would have to do both X and Y checks for outside and inside, correct? If Y is smaller and X is larger, then X is outside and Y is inside? If it could take that into account, this would be an ideal feature.

[jcnventura]

I'd like this to work like the 'contain: automatic' in version 3.2.3. At the starting scale (1), I have the element exactly the max height or width to fit on the screen, and I can move it up, down, left or right as long as the element is not able to leave the screen. Once I zoom in, the element will exceed the screen, but I still am not able to pan higher than the top, lower than the bottom, to the left of the left side, or to the right of the right side. For compatibility reasons, it would be good to keep the same identifier and behaviour.

[timmywil]

Closing in favor of #598. I think if that option were to make it in, it would cover this use case as well, as long as each axis could be independent.

[jcnventura]

This is truly a bug.. I developed the solution to #598 while trying to fix this one, but that doesn't fix this. The problem really is that in these cases the minX > maxY or minY > maxY, and all the logic that calculates result.x or result.y can't handle that case without the change in the #597 PR.

Please re-open this and merge #597 as the fix to this bug.

[timmywil]

@jcnventura technically, it works as documented. If contain is set, it's the user's responsibility to make sure the dimensions are accurate for that use case.

[timmywil]

Regardless, proper implementation of the feature in #598 will fix both.