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: 5/5

The PR appears safe to merge, though the animation-frame throttle still lacks the previously requested non-blocking regression coverage.

Findings

1.  Throttle Lacks Regression Coverage ▶

Summary

• Adds an animation-frame latch around interactionGuard.markActive().
• Removes willChange: "transform" from .cm-scroller.
• Normalizes indentation in the throttle added before the previous review.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Touch or pointer events] --> B[setTouched]
    B --> C{Already touched this frame?}
    C -->|No| D[Mark interaction active]
    D --> E[Schedule animation frame]
    E --> F[Reset touched latch]
    C -->|Yes| G[Skip duplicate update]

Loading

_{Reviews (2) · Last reviewed commit: "fix(android): avoid selection rendering ..."}

[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.