Bug 314881 – Pointer event suppression should be driven by explicit dispatch state, not SyntheticClickType

• Component: UI Events
• Status: NEW

[Abrar Rahman Protyasha]

Element::dispatchPointerEventIfNeeded() uses SyntheticClickType::NoTap as the gate for suppressing pointer-event dispatch on synthetic-click-flow preamble events. This is a proxy signal that pointer events have already been fired upstream because of _some_ compat pathway (most prominently the touch->pointer dispatch in iOS), so don't fire them again here.

The proxy was correct when synthetic clicks were strictly derivatives of touch interactions, but it silently breaks on platforms where synthetic clicks can be initiated without touch interactions. There, the synthesized mouse preamble in `WebPage::completeSyntheticClick()` is the only source of pointer events for an event sequence that leads up to a synthetic click. As such, suppressing it leaves the page with a click event by no complementary pointerdown/up.

A short-term workaround in webkit.org/b/314880 circumvents the early return in dispatchPointerEventIfNeeded() by keying off of InputSource::Automation, but also that only works because the automation input source is currently correlated with configurations with non-touch synthetic clicks. Future callers using this input source may reintroduce the bug if they introduce some independent pointer event dispatch pipeline.

The right architectural fix here is to stop inferring this state and start tracking it explicitly in PointerCaptureController.

[Radar WebKit Bug Importer]

<rdar://problem/177143935>