Repository navigation
Focus is refused on a just-restored window while another window of the same app is key #23
Description
Bug: an agent can't focus a TextEdit window it has just restored while another TextEdit window is key. desktop_focus was refused with "Timeout while waiting for condition", so the agent couldn't type into its document.
Status: #61 may have fixed this. Focus now also trusts AXFocusedApplication, and replaces the bare timeout with activationNotObserved, which names the app. Nobody has rerun the scenario since.
To do:
- Rerun the scenario. Open TextEdit with two windows. Minimize the agent's window, so the other one becomes key. Then call
desktop_restoreanddesktop_focuson the agent's window. - If focus completes, also check that a
desktop_clickin that window makes it key, then close this issue. - If focus is refused with
activationNotObserved, add anAXFrontmostfallback to focus, like the onedesktop_activatehas.
Original report: githubnext/ace#427 R2, on Ace Canary 0.0.46.52.
Activity
iamnbutler commentedon Oct 17, 2026
[-]Focus times out on a restored window while another window of the same app is key[/-][+]Focus is refused on a just-restored window while another window of the same app is key[/+]iamnbutler commentedon Oct 20, 2026
Live check on 0.15.0 (TextEdit, two windows; agent.txt minimized so other.txt was key):
desktop_restoreon agent.txt: completed. agent.txt came back as the key window, and TextEdit was active.desktop_focuson agent.txt: completed (foreground, confirmed change), with noactivationNotObserved. So theAXFrontmostfallback isn't needed.desktop_clickon the text area of the non-key window returnedunknown("did not report AXFocused=true") and didn't make that window key. That's by design: background input never changes the key window, anddesktop_focusis the tool for that. Once focus works, the original scenario no longer needs a click to make the window key.Closing as fixed by #61.