Explain Flutter's GestureArena and overlapping detector scenario

What's really being asked

This question probes whether you understand the boundary between pointer events and gesture recognition in Flutter. It tests knowledge of the GestureArenaManager, the accept and reject lifecycle, and how multiple GestureRecognizers resolve ownership of a pointer stream. Seniors should show they know why hit testing is only the first step and that gesture disambiguation is a separate phase.

The full answer

First, define the arena as a per-pointer scope managed by GestureArenaManager. When a pointer contacts the screen, every recognizer that was hit enters the arena. Second, explain that recognizers are GestureArenaMembers that receive pointer events and vote by calling acceptGesture or rejectGesture. Third, state the resolution rule: the arena closes when only one accepted member remains; that member wins and the others are rejected. Fourth, note that a recognizer can hold its vote until it sees enough evidence, which is why a TapGestureRecognizer waits for pointer up while a DragGestureRecognizer waits for sufficient slop.

The mistakes people make

Candidates often confuse hit testing with gesture resolution, claiming the deepest or topmost widget automatically wins. Some say events bubble up the widget tree like the DOM, which is false; Flutter uses a single-pass hit test and then an arena. Another red flag is describing gestures as synchronous decisions; the interviewer wants to hear that recognition spans multiple pointer events. Saying the framework always prefers scrolling over tapping is also incorrect; the arena decides based on the actual pointer stream.

What usually comes next

How would you make two recognizers cooperate instead of competing? This leads to GestureArenaTeam or RawGestureDetector with custom recognizers. Another follow-up is how to handle a child button inside a scrollable list without arena conflicts, which touches AbsorbPointer, IgnorePointer, or configuring the scroll physics and gesture settings. You might also be asked how the arena behaves when all members reject, in which case nobody wins and the pointer events are effectively dropped for gestures.

A concrete example

Imagine a small card with an onTap GestureDetector nested inside a larger container with a VerticalDragGestureDetector. On pointer down, both recognizers enter the arena. If the user lifts their finger within the tap slop, the TapGestureRecognizer accepts on pointer up. The drag recognizer has not accepted, so the arena stays open until the drag recognizer rejects on pointer up or cancel, leaving Tap as the winner and firing onTap. If instead the user drags past the touch slop, the drag recognizer accepts, the tap recognizer rejects because the pointer moved too far, and the drag wins. The key insight is that neither widget depth nor order alone decides the outcome; the recognizers behavior across the event stream does.