fix(android): reduce selection flicker

[Degrace15]

Fixes #2865.

Reduces repeated interaction-guard updates during code selection by throttling setTouched() to one call per animation frame.

[greptile-apps]

Confidence Score: 4/5

The change appears safe to merge, with a non-blocking need for regression coverage of the animation-frame throttle.

Findings

1.  Throttle Lacks Regression Coverage ▶

Summary

• Adds a module-level latch around interactionGuard.markActive().
• Resets the latch on the next animation frame.
• Preserves the guard’s existing time-based activation semantics.
• Lacks direct regression coverage for the new frame-dependent behavior.

_{Reviews (1) · Last reviewed commit: "fix(android): reduce selection flicker"}

[greptile-apps]

Throttle Lacks Regression Coverage

The new animation-frame throttle has no regression coverage. Existing interaction-guard tests only exercise markActive() and suppress(), so they would still pass if this latch stopped resetting or allowed repeated same-frame updates. Add a test with a controlled requestAnimationFrame that proves a burst causes one update and another update is allowed after the frame; otherwise the selection-flicker fix can regress unnoticed.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[bajrangCoder]

Thanks for looking into this. I don’t think the proposed change has a clear connection to #2865.

interactionGuard.markActive() only updates an activeUntil timestamp using performance.now(); it does not modify the DOM, styles, or rendering state. This PR also leaves the rest of the selectionchange handler - getSelection(), getRangeAt(), and closest() running for every event, so it only throttles the cheapest operation.

The requestAnimationFrame latch also changes the guard’s behavior: if rendering is delayed, subsequent calls are ignored and the 200 ms guard may expire while selection is still active.

Could you please provide:

• A before-and-after recording on the affected device/WebView version.
• Evidence that calls to markActive() are causing the flicker.
• A regression test for the throttling behavior.

Without that validation, the black editor surface shown in #2865 appears more likely to be a WebView/compositor or selection-layer issue, so I don’t think this should be merged.