macOS 27: native app screenshot captures the window-sharing indicator instead of the app window
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
- 54/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- macos, swift, typescript
- Ambito
- desktop, testing-qa
Direzione di ricerca
Start with apple/macos-helper/Sources/AgentDeviceMacOSHelper/BackgroundInteraction.swift and trace onScreenWindows, frontWindow, and the screenshot path through AppWindowScreenshot.frontShareableWindow. Check how accessibility windows can be matched to CGWindow entries, then add regression coverage for screenshots and the frontWindowFrame point check. Done means the app’s main window is selected while the sharing indicator is excluded.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
On macOS 27, agent-device screenshot of a native-backend app session returns the app's window-sharing indicator instead of the app's window. The result is a 132x40 PNG (66x20 points at 2x) of a small "Window" panel.
macOS 27 adds a small layer-0 window to the captured app's own process while anything captures one of that app's windows (here a ScreenCaptureKit stream from another process). The helper's frontWindow takes the first eligible layer-0 window of the pid in CGWindowListCopyWindowInfo order, so the indicator wins over the real window.
Expected: the screenshot captures the app's real main window.
Evidence
- macOS 27.0 arm64, agent-device 0.21.31,
AGENT_DEVICE_MACOS_APP_BACKEND=native, app session on a SwiftUI app (bundledev.stim.desktop.development.hosted1), driven through amacos-applease. agent-device snapshot -ilists the indicator before the real window, as anaxdialognamed "Window" whose only child is a button named "WindowSharingSessionButton" (marked[covered]), then the real window:
@e1 [application] "StimDesktop"
@e2 [axdialog] "Window" [covered]
@e3 [button] "WindowSharingSessionButton" [covered]
@e4 [window] "main"
agent-device screenshot out.pngthen reportsout.png (132x40).- The app's windows from
CGWindowListCopyWindowInfo, filtered to its pid (id, layer, onscreen, width, height, title), from an earlier run with the same symptom:
380 0 1 66 20 Window
264 0 1 1100 850 SwiftUI Playground
- The indicator survives stopping and relaunching the app while the capture continues.
Cause
onScreenWindows(pid:windowInfo:) in apple/macos-helper/Sources/AgentDeviceMacOSHelper/BackgroundInteraction.swift keeps every window with layer 0, on screen, alpha above 0 and nonzero bounds, and frontWindow returns .first. The 66x20 indicator satisfies all of those. AppWindowScreenshot.frontShareableWindow then captures it, since ScreenCaptureKit offers it.
Fix idea
Choose the screenshot window from the app's accessibility windows instead of the first layer-0 CGWindow: prefer AXMainWindow or AXFocusedWindow, or a window whose subrole is AXStandardWindow, and match it to a CGWindow by frame or _AXUIElementGetWindow. The indicator is an AXDialog without a standard-window subrole, so it is excluded. A size floor would be a weaker fallback.
The same ordering may affect any command that uses frontWindowFrame, such as the on-screen point check for click/press, so a regression test should cover both.
Related: #3213 (native backend follow-ups, capture-frame contract), #3761.
- Lingua principale
- TypeScript
- Stelle
- 5.2k
- Fork
- 359
- Merge medio
- 13h 23m
- PR unite (30g)
- 655
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di callstack/agent-device
-
iOS alert wait: the last poll can get ~30 ms and turns "no alert" into a failed readForse già presa @pcbeingused333 l’ha presa 2 giorni fa. Apertabug ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
callstack/agent-device#4018 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
callstack/agent-device#1869 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 18/100
callstack/agent-device#4179 ·
I maintainer di solito rispondono entro 1 giorno
-
Daemon: refuse leased requests that name no session at request admissionForse già presa @airowe l’ha presa oggi. Apertabug ready-for-agent
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
callstack/agent-device#4171 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement needs-triage
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
callstack/agent-device#4162 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di callstack/agent-device
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
ready-for-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
LucasSantana-Dev/Lucky#2951 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
danielmiessler/LifeOS#2567 ·
I maintainer di solito rispondono entro 9 giorni
-
refactor(react-pi): classify base64 images with core's parseBase64Forse già presa @jimmyallinai l’ha presa oggi. Apertamaintenance
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
assistant-ui/assistant-ui#10293 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
brijeshb42/monaco-vim#175 ·