Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Focused composer unavailable after Electron app relaunch

Open
  • Is something wrong?
#1,200 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
electron, macos, swift
Domain
accessibility, desktop

Research direction

Start by tracing the focused-element query and the accessibility preparation path mentioned in the issue; the payload does not identify their file locations. Read Electron’s accessibility guidance and inspect the logged kAXErrorNoValue failure after a fresh app relaunch. Done means the focused composer can be discovered and receive dictation after relaunch while focus, secure-input, and destination-change checks remain enforced.

Written by the indexing model from the issue text.

Description

Describe the bug

After restarting Grok Bot (Electron 42.1.0), FluidVoice transcribes normally but reports No text field focused despite the composer being selected. Inspecting the app with an accessibility tool makes insertion work for that process; restarting Grok reproduces the failure.

Reproduction steps
  1. Restart Grok Bot and click its message composer.
  2. Dictate with FluidVoice and stop recording.
  3. Observe the focus failure and saved transcript.
  4. Inspect Grok's accessibility tree, click the composer and dictate again: insertion works.
  5. Restart Grok and repeat without inspecting it: the failure returns.
Expected behavior

Dictation can discover the focused composer after the target app restarts, without requiring another accessibility tool.

Actual behavior

The system focus query returns kAXErrorNoValue (-25212); delivery correctly refuses because no element is available. FluidVoice does not request the app's accessibility support before capturing its target.

App Version

1.6.12-beta.1 with local #1112 and recovery-copy patches; upstream main 9e3cea53 also has no accessibility preparation path.

macOS Version

27.0

Architecture

Apple Silicon (M1 Max)

Logs or crash report
[14:02:01.496] DICTATION_SUMMARY outcome=success
[14:02:01.499] FOCUS_READ unavailable stage=focused_element axError=-25212
[14:02:01.499] FOCUS_ASSESS unavailable reason=no_focused_element decision=refuse
[14:02:01.499] PIPELINE_SUMMARY outcome=insertionFailed

Electron documents an app-level AXManualAccessibility request for third-party assistive software: https://www.electronjs.org/docs/latest/tutorial/accessibility . Requesting support must not bypass focused-field, secure-input or destination-change validation.

Screenshots or screen recording

The failure was observed before the fix. A local implementation now prepares accessibility on activation and before capture. After a fresh Grok relaunch (new PID), the user confirmed automatic insertion without an accessibility inspector; runtime logs show support enabled, an editable AXTextArea, and successful delivery. The validation build retains the earlier delivery and recovery-copy patches.

Selected diagnostic output

Dominant language
Swift
Stars
11.9k
Forks
863
Avg merge
1d 10h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from altic-dev/FluidVoice

All issues in altic-dev/FluidVoice

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.