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

[BUG] v1.6.11: dictation refuses to paste into the Muse macOS app (focus check reads AXButton); works in Chrome and Gemini

Closed
  • Is something wrong?
#1,109 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@jeevvansh is already working on this.

Since Oct 13, 2026.

  • #1112 by @jeevvansh — open
  • #1127 by @kirolos-esmat — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
macos, swift
Domain
accessibility, desktop

Research direction

Start by reading the delivery-time focus verification and fallback path introduced in v1.6.11; the payload does not name source files or tests. Compare the Muse AXButton result with the successful Chrome and Gemini AXTextArea results, then check how linked pull request #1112 addresses the behavior. Done means dictation pastes into Muse’s focused composer without breaking the existing focus checks.

Written by the indexing model from the issue text.

Description

bug keep-open stale
Describe the bug

Since updating to FluidVoice v1.6.11, dictation into the Muse macOS app (by Meta) fails at delivery. The transcript is produced correctly, but FluidVoice shows the delivery failure notice saying the cursor was not focused anywhere, and nothing is pasted, even though the cursor is clicked into the Muse app's message composer. The same setup pastes fine into Chrome and into the Gemini app. It also worked in the Muse app before v1.6.11.

Environment

  • FluidVoice v1.6.11 (released Oct 12, 2026)
  • macOS 27.0 (build 26A5406e)
  • Text insertion mode: Reliable Paste
  • Accessibility permission is granted and working (the focus check does read an element)

Suspected cause
The new delivery-time focus verification reads the Muse app composer's focused element as an AXButton rather than an editable text element (the composer appears to be a web-view style input). When the focused element cannot be classified as editable, delivery is refused instead of falling back to the previous paste behavior.

Suggested fix
When the frontmost app is not FluidVoice itself and the focused element cannot be positively classified as non-editable, fall back to pasting (the pre-1.6.11 behavior) rather than refusing delivery, or add the Muse app to the set of apps handled by the fallback path.

Reproduction steps
  1. Open the Muse macOS app and click into the message composer so the text cursor is in the field.
  2. Dictate with FluidVoice and stop recording.
  3. The transcript is generated, then the delivery failure card appears (no editable target) and nothing is pasted.
Expected behavior

Text pastes into the Muse app composer, as it did before v1.6.11.

Actual behavior

The transcript is generated, then the delivery failure card appears (no editable target) and nothing is pasted.

App Version

v1.6.11

macOS Version

macOS 27.0 (build 26A5406e)

Architecture

Apple Silicon

Logs or crash report
From ~/Library/Logs/Fluid/Fluid.log:
Controlled A/B test on the same machine, within one minute, after restarting the app:
- 16:39:53, Chrome: `FOCUS_ASSESS editable role=AXTextArea`, outcome=inserted
- 16:40:06, Muse app: `FOCUS_ASSESS notEditable role=AXButton`, outcome=insertionFailed, `Text delivery failed: no_editable_target`
- 16:40:32, Gemini app: `FOCUS_ASSESS editable role=AXTextArea`, outcome=inserted

Earlier failed attempts into the Muse app show the same pattern (15:43 to 15:46, five consecutive `notEditable role=AXButton` failures). Pre-1.6.11 logs show successful inserts into the Muse app.
Screenshots or screen recording

No response

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

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.