Dating back at least to 507efe5a8a2390813fb620a91b0b3b6b383f599d the initial plan was that an ungrab calls setActive(false), and that ought to be enough, because every pointer handler can react to deactivation in its own way. But QQuickTapHandler did not override onActiveChanged(); and it would still not work very well to do that, because setPressed() takes various arguments that are not available in onActiveChanged(). So an odd state of dubious utility was possible: it could be inactive and pressed at the same time. That's now prevented, as long as TapHandler relies on an exclusive grab. If a TapHandler's window is deactivated while it has an exclusive grab, onGrabChanged() is called with a null event, because the deactivation event is not a pointer event. Don't crash, and don't get stuck in pressed state either. Currently in this scenario, the grab transition is UngrabExclusive, not CancelGrabExclusive. If we are sure that a TapHandler should no longer be pressed if its window is no longer active, and one symptom is that it's ungrabbed, probably it makes sense to be consistent that when it loses any kind of grab that it has taken, it should no longer be pressed. But then we would run into the issue with the null event as described above. So these changes are best done together. If a TapHandler's window is deactivated while it has a passive grab, the TapHandler cannot be deactivated or un-pressed, because it is not in active state in the first place. (As documented, `active` means it has an exclusive grab.) Fixes: QTBUG-118454 Fixes: QTBUG-124777 Change-Id: I855a0e0ddcb13866af5501f6164b6b18b41dda2a Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>