chat-ui

e81435e6 - Grant artifact preview iframes safe capabilities (pointer lock, sensors, fullscreen) (#2469)

Grant artifact preview iframes safe capabilities (pointer lock, sensors, fullscreen) (#2469) * Grant artifact preview iframes safe capabilities (pointer lock, sensors, fullscreen) The preview sandbox only allowed scripts and forms, so generated apps that use pointer lock (mouse-look games), devicemotion/deviceorientation (mobile tilt controls), fullscreen, gamepad, autoplay, clipboard writes, or alert/confirm silently broke, and models shipped workarounds instead. Both preview surfaces (artifact panel and fullscreen modal) now share exported PREVIEW_SANDBOX / PREVIEW_ALLOW constants: the sandbox gains allow-pointer-lock, allow-modals and allow-orientation-lock, and the allow attribute delegates fullscreen, pointer-lock, accelerometer, gyroscope, magnetometer, gamepad, autoplay, clipboard-write and screen-wake-lock with explicit * allowlists (an opaque origin cannot reliably match the default 'src' keyword across engines). The fullscreen modal also gains allow-forms, which the panel already had. The security boundary is unchanged: no allow-same-origin (opaque origin, no app cookies/storage/DOM), no popups, no downloads, and no delegation of privacy-sensitive inputs (camera, microphone, geolocation, clipboard-read, display-capture). Browser tests pin both the grants and the denials inside a real opaque-origin frame, and the artifacts system prompt now documents what generated code can and cannot use. * Drop allow-modals from the preview sandbox Previews auto-open with zero clicks (shared conversations open the latest artifact on load, and streaming auto-opens in-session), and a dialog from a same-process srcdoc iframe blocks the parent's event loop, so a while(true) alert() artifact would hold the tab hostage with the panel's close button dead between dialogs. Dialog calls are silent no-ops without the token; the system prompt now steers models to in-page UI instead, which also behaves identically in previews and deployed Spaces. * Drop screen-wake-lock from the preview delegation Wake lock needs no user gesture, previews can open with zero clicks (shared conversations, streaming), and a silent lock would keep a walked-away-from display awake. Previews gain nothing from it in return: they are an active-use surface where interaction keeps the screen on anyway. The capability probe now asserts the denial.