Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Toolbar: prior dictation recovery hides active and paused Read controls

Aperta
  • Qualcosa non va?
#220 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
macos, swift
Ambito
accessibility, desktop

Direzione di ricerca

Start with Sources/LocalVoice/FloatingToolbar.swift, especially FloatingResult.pending (lines 43–49) and FloatingToolbar.content (lines 147–150), then trace the application-method/result-selection seam and production host. Reproduce the mixed state with an older dictation recovery and Read preparing, playing, and paused; verify the revealed controls match the live reading state while preserving the recovery. Cover the collision at the selection seam and through the production host, then repeat the playing and paused checks in signed installed Preview.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Outcome and priority

P2 functional defect, reproduced in installed Preview. An older dictation recovery takes over the revealed floating toolbar during a new active or paused reading. The compact mark correctly reports Read, but its click reveals Retry transcription / Record again instead of the reading's controls. The person must reopen the main Read page to pause, resume or stop.

Build and native reproduction

Workbench Preview 2.3.0, build 20260928223302, clean source c3fff97d686c2f6a575c2967abc81cc49bc4d8d4, macOS 26.5.1 (25F80), Apple M5. Verified through fresh in-app Copy build details and native Paste, with bundle metadata cross-check. Integration held installs for this segment.

  1. Start with an existing unretried dictation recovery. Home says “A capture is kept for recovery”; the toolbar's recovery card says “A recording was recovered. Use Retry transcription.” Leave it intact.
  2. On Read, enter synthetic text (this run: 2,458 characters), use a Mac voice at 180 words/min, and choose Listen.
  3. Close the main window. The compact toolbar's accessible description is Read, its help is “Reading aloud”, and its value is “Reading aloud, Needs attention”. It is compact, with no separate reading HUD observed.
  4. Click the compact mark once. The revealed content is Dictation needs attention, Retry transcription, Record again, and Dismiss dictation error. There is no Pause or Stop reading in that pointer-revealed content.
  5. Reopen the main window through Window > Open Workbench. Read is still playing: 31.125375 seconds of 2:43, with Pause and Stop available there.
  6. Pause on Read at 38.869375 seconds, close the main window and click the compact mark again. Its help says “Reading paused” and its value includes Paused, but the same old dictation recovery card appears, with no Resume or Stop reading.

Observed in both playing and paused states within one native run. Returning to the main Read page preserved the paused playhead exactly. Stop there worked; the original Read draft, voice and pace were restored, and the old recovery remains available. No recovery was retried or dismissed. Private AX/screenshots remain in the QA session.

Native counterexample: focused entry works

On the same build with the same recovery still pending, Window > Focus floating toolbar revealed the ordinary Read row. Pause reading changed to Resume reading; Resume restored Pause reading. More kept the old recovery commands under Dictation needs attention and separately offered Read > Stop reading. That Stop ended only the synthetic reading. This narrows the failure to pointer-result presentation overriding the live row; the transport owner itself worked. Read text, voice and pace were restored again.

Owner and bounded cause

FloatingResult.pending, lines 43–49 checks dictation phase/preview state, then returns .dictationFailure for any captureFailure. It does not first exclude active/preparing/paused Read. Only its subsequent reading-failure branch checks the reading lifecycle.

FloatingToolbar.content, lines 147–150 gives that pending result the whole pointer-revealed surface instead of the live action row. This disagrees with the method's own “if nothing live has taken the host since” rule and #134's active-work priority. Batch 5 head 159254985957681c7d6d665c0a934a415c339b8b still has the same pending-result gate; its timer/menu/accessory changes do not repair this case.

Resolve deferred results against the same live-state priority used by the truthful next action. Preserve the old recovery and its warning; do not fix this by clearing its error, retrying it or discarding its journal when Read begins. Make it reachable again after the newer work ends. Keep the one host and existing state owner.

Acceptance

  • With an old synthetic dictation recovery present, Read preparing/playing/paused reveals Cancel generation, Pause or Resume respectively, with Stop reading reachable where applicable. The mark and revealed controls agree.
  • Clicking the compact mark still only reveals; it never pauses, retries or starts an unrelated capture on that first click.
  • The old recovery's text/audio/journal survive starting, pausing, resuming and stopping Read, with no replay. Its recovery controls remain reachable after Read ends.
  • Cover the mixed state at the application-method/result-selection seam and through the production host. Separate “reading alone” and “recovery alone” snapshots do not cover this collision.
  • Check the corresponding active-owner gate for narration and dictation with older deferred results; those combinations are regression scope, not additional native failures claimed by this report.
  • Repeat the playing and paused pointer-reveal steps in signed installed Preview and record Copy build details. Record keyboard-entry behavior separately; it may take a different host path.

Child of #134 T4/C1/C8, found during its installed retest; indexed by #164. Searched existing open/recent recovery+toolbar and reading+toolbar requests; #152 owns geometry and #156 owns routine cues, neither this result-versus-live priority failure. No implementation or acceptance is claimed.

Lingua principale
Swift
Stelle
0
Fork
1
Merge medio
8h 5m
PR unite (30g)
215

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ship-Work/workbench

Tutte le issue di Ship-Work/workbench

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.