Re-Read the Native Target

"Don't ask 'is an app there?' Ask 'is the exact thing I captured still there?' Those are very different questions."

Re-Read, Don't Trust

For a native Accessibility target, proving the snapshot means re-reading the world and comparing it, attribute by attribute, to what you captured. You go back to the system-wide element, read the focused element again, read its selected text and range again — the same chain from Track 3, but now run a second time, at insertion. The point isn't to re-derive the target; it's to check whether the target you already have still describes reality. Trusting the old snapshot skips exactly the step that keeps you safe.

What Must Match

A native re-proof compares several things, and all of them must agree: the frontmost app and its process id, so you're in the same app instance; the focused element's role and identity, so you're in the same field; and, most importantly, the selected text and range, so the exact characters you meant to replace are still the ones selected. That last check is what separates Flint's guard from a weaker one. Same app isn't enough. Same field isn't enough. The same selection is the bar, because that's what's about to be overwritten.

SNAPSHOT (t0)          RE-READ (t1)           verdict
---------------------  ---------------------  -------
app bundle + pid       app bundle + pid       must match
focused element role   focused element role   must match
selected text          selected text          must match
selected range         selected range         must match
                                              all match -> replace
                                              any differ -> refuse

Replacing Exactly the Selection

Once the re-proof passes, the native replace is precise: set the focused element's selected-text attribute to the transformed result, which overwrites exactly the currently-selected range. Because you just proved that range is still the one you captured, the overwrite lands exactly where the user meant it. This is the cleanest possible insertion — no clipboard, no synthetic keystrokes, just a direct, scoped replacement of the proven selection — and it's available precisely because the native target let you re-verify the range first.

Compare observable attributes, not pointer identity. An AXUIElement reference captured at the strike is not a reliable handle to compare across the gap — the same field can hand back a different reference, and a stale reference can dangle. So don't prove 'is this the same object pointer?' Prove 'does the currently focused element report the same app, role, selection, and range?' Identity you can trust is the identity you can observe and re-read, not a handle you cached.

Verify every dimension of the intent, not a convenient proxy for it. It's tempting to check the cheapest thing — 'the right app is frontmost' — and call it proof. But the intent had several dimensions (app, field, selection, range), and a stale target can match the cheap one while failing the rest: right app, wrong selection. Prove the whole intent, especially the dimension that's about to be destroyed. A proxy check is how a guard passes and still overwrites the wrong text.

Code

Prove a native target by re-reading and comparing·swift

func proveNative(_ snap: TargetSnapshot) -> AXUIElement? {
    // Same app instance?
    guard let front = NSWorkspace.shared.frontmostApplication,
          front.bundleIdentifier == snap.appBundleID,
          front.processIdentifier == snap.pid else { return nil }

    // Re-read the focused element and its selection NOW.
    guard let now = readSelection() else { return nil }   // Track 3's read

    // The selection and range must still be exactly what we captured.
    guard now.text == snap.selection,
          now.range == snap.range,
          now.role == snap.role else { return nil }

    return now.element   // proven: safe to replace this exact selection
}

func replaceSelection(with result: String, in element: AXUIElement) {
    // Overwrites exactly the currently-selected (and just-proven) range.
    AXUIElementSetAttributeValue(
        element, kAXSelectedTextAttribute as CFString, result as CFTypeRef)
}

Exercise

A guard checks only 'is the same app frontmost?' before replacing the selection. Construct a concrete scenario where that guard passes but the replacement destroys the wrong text. Then list the additional dimensions Flint compares to close that hole, and say which single dimension is the most important given that Flint overwrites rather than inserts.

Hint

Scenario: same app is frontmost, but during the wait the user clicked to a different paragraph and selected other text — the app matches, the selection doesn't, and the replace overwrites the new selection. Flint additionally compares pid, focused-element role, selected text, and range. The most important is the selection/range match, because that is exactly the content about to be overwritten; matching everything except the selection is matching everything except the thing that matters.

Re-Read the Native Target

Re-Read, Don't Trust

What Must Match

Replacing Exactly the Selection

Code

External links

Exercise

Progress

Comments 0