forcepress on iOS

[alexreardon]

Right now, if you call event.preventDefault() on a touchforceevent it will opt out of a lot of standard browser behaviours including clicking a scrolling.

I suspect this is a recent change in webkit, and I have raised a bug on their project. Unfortunately, we cannot just wait for them, we need to find a path forward, even if it is only temporary.

Right now it is a delicate dance to enable drag and drop interactions in force press compatible environments.

Background

Force press interactions on iOS allow for additional interactions on elements. The most notable is links prevents and navigation by applying different levels of pressure to an element

shouldRespectForcePress={false} (current default)

This allows users to disable force press interactions and allow dragging with any pressure applied.

Call event.preventDefault() for all touchforceevent events after touchstart

💥This is now breaking scrolling #1396 and clicking #1367 on iOS.

shouldRespectForcePress={true} (10.x default)

With this option we try to respect standard force press interactions as much as possible. We moved away from this as the default as people trying to drag might apply too much pressure and have their pending drag cancelled and not know why.

• Cancel a pending if we detect a force press (touchforceevent with enough pressure)
• If dragging and the user has not moved at all: we cancel the drag and allow the force press interaction
• If dragging and the has moved the draggable: then we call event.preventDefault() on touchforceevents to prevent force press actions mid-drag.

Workaround

I have tried a number of potential workaround strategies. The only one that seems to be viable is this:

• only call event.preventDefault() on touchforceevent after a force press is recognised (once enough pressure is registered). This is rather than doing it on every event
• reduce the time to lift from 150ms to 120ms. This seems to be safely inside of the time that webkit gives for registering a force press interaction. This is not ideal as I have noticed it can interfere with slightly slower click interactions

I think this is the best path forward for now. Hopefully, webkit will action the bug I raised and we can change things back to how they were

TODO:

• Verify workaround works and has no significant gotchas
• Investigate webkitmouseforcechanged and if it needs the same workaround
• Write tests
• Backport fix from 12.x alpha to 11.x

[alexreardon]

I have shipped the workaround in an alpha for validation:

12.0.0-alpha.7

[alexreardon]

This is now mostly fixed on 11.0.5. Will we will re-enabling force press opt out for touchpads in 12.0

[alexreardon]

#1317