Weird scrolling issues in iOS web views

[blutorange]

We had an issue similar to #626, where the page would scroll and the user could not draw a signature. I'm making this a discussion instead of an issue since I don't have any way to debug it any further. Perhaps this helps somebody with similar issues.

Now the curious part about this is that it worked on almost every browser and device (including an iPhone with Safari). The only environment where the scrolling issue occurred was when the web page with the signature was viewed inside a UIWebView of an iOS app. UIWebView is currently deprecated in favor of WKWebView, I do not develop the app and cannot test if updating to WKWebView would solve the issue.

I also do not have access to an iPhone, but a colleague working remotely does. We were at least able to come up with a workaround. The canvas with signature pad is inside a div, and once we added an event listener for the touchmove event to the container div that prevents the default (and also stopped its propagation for good measure), the scrolling issue disappeared and signatures could be drawn again (incidentally, settings touch-events: none on the container div did not help, as was also mentioned in #626)

I find this strange, as it seems this library already registers a listener on the canvas and stops the default, but this might be specific to iOS web view, as the signature pad on same web page works perfectly when the web page is viewed directly in the Safari browser on the same device.

[UziTech]

What version of signature_pad are you using and are you using it directly or through another package (e.g. react-signature-canvas)?

[blutorange]

We're using the vanilla library directly, so no react or anything. It's used as a widget inside an HTML form to let people draw a signature. There is some additional JavaScript that handles form validation etc., and I won't rule out that there could be some interaction here, although I think it's likely, since that JavaScript only registers some change handlers and doesn't do anything with touch events. Other than that, the iOS app is basically a simple web view that displays the HTML form (which stores all entered data and lets people submit it later when they are connected to the internet).

It is unfortunate that I don't have direct access to an iOS device to inspect this issue further, as they were several issues were people reported issues with iOS devices, but I though I'd at least report what we found.

We originally tried it with version 4.1.5, but we also updated to version 4.1.7 (taking a look at the changelog, there shouldn't be any relevant change).

[UziTech]

We already do preventDefault on touchmove to prevent scrolling

signature_pad/src/signature_pad.ts

Lines 282 to 290 in 3498084

	private _handleTouchMove = (event: TouchEvent): void => {
	// Prevent scrolling.
	if (event.cancelable) {
	event.preventDefault();
	}
	const touch = event.targetTouches[0];
	this._strokeMoveUpdate(touch);
	};

Since you said it happens in web view not safari I wonder if web view uses pointer events instead of touch events. I also do not have an iOS device to test on. If you find a fix and create a PR I can merge it.

[blutorange]

Yeah I've seen that, but it's registered on the canvas element itself. Once I registered the listener on the surrounding div element, my colleague with the iOS device said the issue was fixed. It's weird - since they could then draw on the canvas, the event must have reached the canvas, but then it should have gotten its default prevented in the first place. I don't really want to make a change that I'm not sure really fixes the issue (and why), but if I somehow manage to get access to an iOS device, I'll take another look.