You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Dots][cloud computer] Chrome text input fails with unavailable AT-SPI provider while screenshots and clicks work #52199
Observed October 8, 2026 in a dot-managed Linux/X11 cloud computer, native Chrome window controlled through cua_repl. Cloud image, Chrome, and CUA build versions were not captured. The user's separate macOS desktop version should not be treated as the cloud runtime version.
Observed sequence
Reuse an existing signed-in browser tab. Screenshots and mouse clicks work, and the intended page is accessible.
Attempt harmless text entry in the address bar through the native app's typeText operation.
Text entry fails immediately: AT-SPI provider with process ID [redacted] is unavailable for X11 window [redacted].
Native paste and documented desktop type_text operations fail through the same provider path.
Rebind the app/window, reset the CUA runtime, obtain fresh state and screenshot, and repeat a harmless typing test. The same failure persists.
Expected / actual
Expected: authorized text entry into a focused Chrome control succeeds or a supported recovery path is available.
Actual: visual reads and clicks work, but typing/paste cannot proceed. A legitimate administrative workflow was stopped before any settings were saved. No website authentication problem or missing user authorization was observed.
Boundaries
This is an observed sequence, not a clean-image minimal reproduction. Root cause is unconfirmed. No private account identifiers, URLs, content, credentials, screenshots, or task/session IDs are included. The separate local Mac delegation/control problem has not been established as related.
Related: #49726 describes Linux cloud bulk text input/AT-SPI failures in other native apps; #50414 mentions a native keyboard AT-SPI error with browser-level typing still working. These are related symptoms, not proof of a shared cause.
Please investigate the cloud accessibility/input provider lifecycle and document a supported recovery or browser-level fallback.
Additional observation from a dot-managed Linux/X11 cloud computer on 2026-10-12 (UTC), using Chromium:
Native bulk text input fails with AT-SPI provider with process ID [redacted] is unavailable for X11 window [redacted].
Screenshots, visual reads and mouse clicks remain available. Public HTTPS pages load, and browser/CDP accessibility reads work.
We closed Chromium normally through its UI and relaunched it, preserving the existing profile. The browser process ID changed, confirming an actual browser restart.
After relaunch, native type_text still failed with the same AT-SPI provider error, now referring to the new browser process.
Restarting the browser alone did not resolve the native input failure in this session. We did not clear the profile or reset the whole cloud computer or dot. This is a session observation, not a clean-image reproduction; the root cause remains unconfirmed.
I think I'm running into the same issue. Debugging information from my dot:
I’m seeing what appears to be the same issue on a dot cloud computer running Linux/Chromium, on October 15, 2026, around 10:37 UTC. I’m accessing dot through a web browser on macOS.
What works:
Computer inventory lists Chromium as running.
Retrieving its window succeeds, reporting “Accessibility source: x11”.
Screenshots work.
Sending Ctrl+L works: a subsequent screenshot confirms the address bar is focused.
What fails:
Calling typeText('google.com') on the Chromium window throws:
AT-SPI provider with process ID is unavailable for X11 window <WINDOW_ID>
Trying sky.type_text({text: 'google.com'}) produces the same error.
The intended next step was Return, but it was never executed because typing threw. No navigation occurred.
Activity
KnotLogic commentedon Oct 12, 2026
Additional observation from a dot-managed Linux/X11 cloud computer on 2026-10-12 (UTC), using Chromium:
AT-SPI provider with process ID [redacted] is unavailable for X11 window [redacted].type_textstill failed with the same AT-SPI provider error, now referring to the new browser process.Restarting the browser alone did not resolve the native input failure in this session. We did not clear the profile or reset the whole cloud computer or dot. This is a session observation, not a clean-image reproduction; the root cause remains unconfirmed.
raphaeltm commentedon Oct 15, 2026
I think I'm running into the same issue. Debugging information from my dot:
I’m seeing what appears to be the same issue on a dot cloud computer running Linux/Chromium, on October 15, 2026, around 10:37 UTC. I’m accessing dot through a web browser on macOS.
What works:
What fails:
AT-SPI provider with process ID is unavailable for X11 window <WINDOW_ID>
The intended next step was Return, but it was never executed because typing threw. No navigation occurred.