Add alternate touch event models

[abrin]

@stephenwf I've found that adding a touch-model interaction on-top of the canvas-panel isn’t working. Instead, it would work better if it was built into the Atlas interaction model. I'm more than open to thoughts and ideas here too.

This helps address some of this more cleanly:

1. it addresses the fact that the browser-event-manager registers duplicate event listeners without removing them

2. it removes the touch-action: none; and pointer-events: none; which was preventing the window from listening to scroll based touches.

3. it replaces the above with making sure that e.preventDefault() is called when we don’t want to scroll because this does the same thing see this:

Applications using Touch events disable the browser handling of gestures by calling preventDefault(), but should also use touch-action to ensure the browser knows the intent of the application before any event listeners have been invoked

4. With this set, we can now use e.preventDefault() in various places to determine when we want the event to be passed to the window.

5. I also added some custom user-select settings to make sure that a long touch doesn’t try to select in Safari

6. I also found that binding touch-move to the window was causing issues, so I bound it to the parent element of the canvas.

New interaction modes:

1. ignoreSingleFingerTouch when this is enabled a single finger touch does nothing, instead of panning, it allows the window to scroll.

2. enablePanOnWait in this interaction model it assumes that a user will wait a brief moment between when the press and when the move when the intent is to “pan.”

**Question: can I modify the popMotionController arguments in CanvasPanel — is this a matter of defining and setting them in the useAtlas setup in CanvasPanel?

[codesandbox-ci[bot]]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[stephenwf]

This looks great @abrin! Solves a lot of long-standing issues things in one go. I'll read in more depth soon.

[abrin]

@stephenwf I think this one is ready. We're trying to test and fine-tune what the timing should be, but the way that it's configured, this can be controlled though CanvasPanel now --> https://github.com/digirati-co-uk/iiif-canvas-panel/pull/264 . I believe I've flipped the defaults all back to the point that they match the current behaviors.

[stephenwf]

Thanks @abrin, having a look now!

[stephenwf]

@abrin looks good! I think I'll be using these options by default, but I agree that keeping it the same makes sense 👍 Do you want me to go ahead and merge?

I'll need to merge it into the 2.0.x branch too, but should be smooth.

The current main canvas panel branch is on 2.0.x of this repository but the PR I've opened gets everything back up to the latest versions of everything.

https://github.com/digirati-co-uk/iiif-canvas-panel/pull/237

[abrin]

@stephenwf I think this work is ready. As with anything, there may be bugs and edge-cases... but in all the testing we've not seen any in particular. I will let you know where we end up with the interaction model and the timing. We're going to run some user-testing internally that helps us refine what the delay should be.

[stephenwf]

That would be great, thanks. I'll get this merged up.