Add support for gesture reactions constraint

[jan-ivar]

Fixes #118 (preliminary, for discussion)

---

Preview | Diff

[eladalon1983]

Rather than reactions, this should be in the vein of heuristicReactions or heuristicEffects.

The problem we seek to solve is that gesture-driven reactions misfire and effects are injected in contravention of the user's actual intentions. Having a heuristicEffects control would help prevent that.

In contrast, if we specified reactions, that would allow an app to suppress the user's explicitly delivered intentions (e.g. via menu interaction).

[jan-ivar]

AVCaptureDevice (canPerformReactionEffects) appears to call them "reaction effects", i.e. effects in response to user reactions.

IOW, the word "reaction" refers to the "user reaction" that triggers the effect, not the effect itself.

Thinking of it this way, the word heuristic seems captured by reaction. E.g.

reactionEffect = heuristic effect vs. explicitlyTriggeredEffect = non-heuristic triggering of the same effect through clicking on this menu:

So maybe track.getSettings().reactionEffects?

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC March 26 2024 meeting – 26 March 2024 (Should web applications be aware of reaction effects added by OS to camera feeds? #118):

RESOLUTION: Proceed with proposal based PR #141, with name bikeshedding left to editors

[youennf]

Either heuristicReactions or gestureReactions would be fine to me.

[jan-ivar]

@eladalon1983 WDYT?

[eladalon1983]

LGTM