Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug]: macOS Accessibility warning persists after permission is enabled

Abierto
  • ¿Algo no está bien?
#1,196 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
50/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
electron, macos, typescript
Área
desktop

Línea de trabajo

Start in src/hooks/useScreenRecorder.ts, where the darwin editable-overlay preflight calls requestNativeMacCursorAccess and shows recording.cursorAccessibilityUnavailable on a not-determined helper result. The proposed change removes that toast and the System Settings prompt, keeping the position-only fallback. Done means a regression test shows recording starts without the Accessibility toast, and the change is checked on a macOS build.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Search existing issues
  • I have searched the existing issues
  • Related: #878 and merged fix #886
Describe the bug

On macOS, OpenScreen can still show the Accessibility warning even after Accessibility is enabled for the OpenScreen app in System Settings.

Observed message:

Accessibility is off. Recording will continue, but cursor effects may be limited. Enable it in System Settings for full cursor effects.

The warning is misleading in this state: the main app is authorized, recording can start, and the warning appears to be based on the result of a separate native cursor helper process rather than the main OpenScreen app's TCC grant.

This was first observed in a local 2.0.1-hans.7 build and reproduced in a local arm64 build based on the official v2.0.0 code line. I have not yet claimed that it reproduces in the unmodified notarized v2.0.0 DMG.

Expected behavior
  • Accessibility should be treated as optional for recording.
  • If the main app is authorized, no Accessibility warning should be shown.
  • If Accessibility is unavailable, recording should still start with position-only cursor telemetry, without repeatedly opening System Settings.
  • A warning should only be shown when the app can reliably determine that the main app's permission is missing.
To Reproduce
  1. On macOS, enable OpenScreen under System Settings → Privacy & Security → Accessibility.
  2. Restart OpenScreen.
  3. Use the cursor/editable-overlay recording mode.
  4. Start a recording.
  5. Observe that the Accessibility warning can still appear even though the permission is enabled.
  6. The recording itself can still succeed.
Environment
  • OS: macOS 26.6.2
  • Architecture: Apple Silicon (arm64)
  • Official release line: v2.0.0
  • Bundle identifier: com.etiennelescot.openscreen
Proposed fix

Treat the native cursor-access request as best-effort and do not use its helper-process status as a recording-start gate or as proof that the main app lacks Accessibility.

In src/hooks/useScreenRecorder.ts, the recording preflight can be reduced to:

if (platform === "darwin" && cursorCaptureMode === "editable-overlay") {
  await window.electronAPI.requestNativeMacCursorAccess();
}

Remove the recording-start path that:

  • tracks cursorAccessibilityWarningShown;
  • shows recording.cursorAccessibilityUnavailable based on a not-determined helper result;
  • opens System Settings from that toast.

Keep the native cursor session's position-only fallback and add a regression test asserting that recording starts and the misleading Accessibility toast is not shown.

I applied this change locally. Targeted tests passed, and a real 87.9-second H.264/AAC recording completed successfully.

Separate packaging note

During local testing, an ad-hoc package whose main executable identifier was Electron produced SCStream -3805 (application connection interrupted). Restoring the official bundle identifier com.etiennelescot.openscreen and preserving the correct app identity removed that failure. This appears to be a local packaging/signing issue rather than an upstream runtime regression, but the release packaging should continue to preserve the app bundle identity.

Lenguaje dominante
TypeScript
Estrellas
3.7k
Forks
231
Merge medio
15 h 10 min
PR fusionados (30 d)
324

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getopenscreen/openscreen

Todos los issues de getopenscreen/openscreen

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.