[web] Don't debounce physical mouse clicks in ClickDebouncer - #192641

Fixes #188859

Problem

When semantics is enabled, Tappable marks every tappable node with flt-tappable. ClickDebouncer then withholds pointer events that land on such a node and, when the DOM click arrives, synthesizes a generic SemanticsAction.tap in their place and drops the queued pointer events.

The framework turns that action into a tap at the center of the widget with PointerDeviceKind.unknown. So with ensureSemantics() active, a GestureDetector under a physical mouse cursor gets Tap*Details with the wrong position and the wrong device kind.

Fix

Forward physical mouse input straight to the framework rather than debouncing it. The DOM click that follows is then deduped by the existing _shouldSendClickEventToFramework check, because the forwarded pointerup sets _lastSentPointerUpTimeStamp. No double-fire.

This also removes the 200ms press latency that mouse clicks on a tappable node currently incur.

⚠️ Known issue: this also captures screen-reader activation on Chrome

Putting this up front because it is the thing that needs a decision before this can land. I went looking for what pointerType assistive technologies actually report. The two engines differ, and Blink is the problem:

Blink / Chrome — event_dispatcher.cc dispatches a full pointerdown → mousedown → pointerup → mouseup → click sequence for SimulatedClickCreationScope::kFromAccessibility, and simulated_event_util.cc hardcodes the pointer type:

initializer->setPointerId(PointerEventFactory::kReservedNonPointerId);
if (creation_scope == SimulatedClickCreationScope::kFromAccessibility) {
  initializer->setPointerId(PointerEventFactory::kMouseId);
  initializer->setPointerType(pointer_type_names::kMouse);
  initializer->setIsPrimary(true);
}

Coordinates are set to the element's border-box center (not 0,0), and isTrusted is true. So on Chrome, AT activation is indistinguishable from a physical mouse click by pointerType, pointerId, isTrusted, coordinates, or detail.

Incidentally this also identifies the sequence described in #174046 as the Blink path, not Safari.

WebKit / Safari — unaffected. AccessibilityObject::press() goes through in-engine dispatchSimulatedClick, which emits mousedown/mouseup/click and no pointer events at all; the lone click PointerEvent is spec-compliant with pointerType = "" and pointerId = -1. _maybeStartDebouncing is never reached.

What that means in practice

On Chrome, a screen-reader activation now takes the new early return, so the subsequent click is deduped and no SemanticsAction.tap is sent. Activation instead becomes a real down/up tap at the widget's centroid:

• Node with a hit-testable gesture recognizer (GestureDetector, InkWell, most buttons) — still activates, with better fidelity than before.
• Semantics(onTap:) node with no recognizer under the centroid — silently stops responding to screen-reader activation.

That is the same trade described below, but extended to AT users, which raises the stakes a lot. I don't think I should pick the resolution unilaterally. Options as I see them:

1. Land as-is, on the argument that a centroid tap through a real recognizer beats a positionless SemanticsAction.tap, and recognizer-less Semantics(onTap:) is rare.
2. Keep debouncing and instead flush the queued pointer events when the click arrives — the isListening == false branch already does this. Preserves AT behavior exactly; gives up the 200ms latency win.
3. Something smarter I haven't thought of.

/cc @yjbanov @mdebbar — you two own this code path; I'd rather have your call than guess.

Trade-off (independent of the above)

Stating plainly, since it is also documented at the call site: mouse input can no longer reach SemanticsAction.tap by any route. The engine cannot know whether the framework consumed the pointer gesture, so there is no version of this fix that keeps both.

Only pointerType == 'mouse' is exempted. pen and touch lose the same detail for the same reason, but touch is the case the debouncer was written for and both were in scope when the 200ms window was tuned, so widening the exemption felt like a bigger swing than this fix warrants.

Tests

• Existing _testClickDebouncer cases migrated from context.primaryDown()/primaryUp() to local touchDown()/touchUp() helpers, since mouse no longer debounces.
• New regression test: mouse pointerdown/pointerup on an flt-tappable node reach the framework as pointer packets, and the following DOM click does not additionally fire a SemanticsAction.tap.

Possibly also fixed

From the code path these look like the same root cause, but I have not reproduced them:

• [Web]: With SemanticsBinding.instance.ensureSemantics(), the secondary widget in RadioListTile becomes noninteractable via mouse in ^3.19.0 #146063 (secondary widget in RadioListTile becomes noninteractable via mouse)
• When ensureSemantics is On can't click on RadioListTile secondary item #177314 (duplicate of the above)