How is Edit Mode supposed to capture and replace selected text?

[scott-edwards-economist]

Hi,

Before opening a GitHub issue, I wanted to check whether I am misunderstanding the intended workflow or missing a required permission or setting.

I'm trying to use Edit Mode as follows:

1. Select text in an application.
2. Press the Edit Mode shortcut (Option+R).
3. Confirm that the FluidVoice overlay changes to blue/Edit Mode.
4. Speak an instruction, such as:

   Remove every second word in this sentence.

5. Press the shortcut again to stop recording.

Normal dictation works correctly for me in both Visual Studio Code and Slack. However, Edit Mode does not modify the selected text. I also tested the same workflow in Apple's built-in TextEdit, with the same result.

The logs show that the shortcut and voice recording work, but selected-text capture fails:

Rewrite mode shortcut triggered - starting
Selection capture start
Frontmost app fallback could not resolve focused element
Selection capture failed: no selected text found
Rewrite mode triggered, text captured: false
No text selected - starting in write/improve mode

The transcription itself completes successfully, but FluidVoice then reports:

Processing write/improve ... originalText length: 0
Rewrite failed - no result

This seems to indicate that FluidVoice is entering write mode because it cannot capture the selected text.

Accessibility permission is enabled for FluidVoice under:
System Settings → Privacy & Security → Accessibility

Microphone access is also enabled, and normal dictation works as expected.

Could someone please clarify:

• Is this the correct Edit Mode workflow?
• Are there any additional permissions or Edit Mode-specific settings required?
• Is selected-text editing expected to work in TextEdit?
• Is there a known issue with selected-text capture on macOS?
• Could I be missing a step before reporting this as a bug?

I’m asking here first to make sure I’m not doing anything incorrectly before opening a GitHub issue.

[yhay81]

Your workflow is correct, and selected-text editing is expected to work in TextEdit. There is no separate Edit Mode permission: microphone access is needed for the instruction, and Accessibility access is needed to read/replace the selection.

The important part of the log is not merely that no selected text was returned; it is that both attempts to obtain the focused Accessibility element failed:

Frontmost app fallback could not resolve focused element
Selection capture failed: no selected text found

In the current implementation, Edit Mode calls captureSelectedText() before showing/advancing the overlay. TextSelectionService first asks the system-wide AX element for kAXFocusedUIElementAttribute, then retries against the frontmost application's AX element. Only after that does it read kAXSelectedTextAttribute (or a selected range). Your log also does not contain the service's explicit “Accessibility permissions not granted” message, so the trust check appears to pass; the failure is resolving the focused element.

This is the same failure already reported in issue #259, including the same log lines. Since you also reproduce it in TextEdit, it is unlikely to be only VS Code/Slack failing to expose their accessibility trees.

I would try one clean TCC re-registration before adding your reproduction to that issue:

1. Quit FluidVoice completely.
2. In System Settings → Privacy & Security → Accessibility, remove FluidVoice (not just disable it).
3. Launch the exact installed app you intend to use, add/enable it again, then quit and relaunch once more. This especially matters after moving the app or switching between release and locally built/signed copies.
4. In TextEdit, select text and press the shortcut without clicking the FluidVoice overlay.

If the same two lines remain, you are not missing a step; this is a bug worth reporting on #259. Useful diagnostics would be the FluidVoice version/build, macOS version, whether it is a release or local build, the app's install path, and the complete [TextSelectionService] lines. If possible, also check the selected TextEdit field in Accessibility Inspector—whether it exposes a focused element and AXSelectedText will distinguish a macOS/TCC problem from FluidVoice's lookup path.

One separate note: Rewrite failed - no result can also indicate an Edit Mode provider/model configuration problem, but that occurs after selection capture. Fixing the provider would not explain the earlier focused-element failure, so I would diagnose selection capture first.