Android ChatGPT renders an Apps SDK widget inline, but requesting fullscreen can produce a blank surface with only the host composer visible. Android Back restores the same inline widget.
Color clarification: the blank surface was black in our dark-mode tests. In light mode, the empty host background may be white; we have not verified light mode. The failure is missing widget content, not a particular background color. References to a “blackout” below describe that dark-mode observation.
This still reproduces after reducing the app to a plain 916-byte HTML canary: no frontend SDK, CSS, fixed/viewport heights, framework, reader payload, state restoration, or data fetching. The same canary renders fullscreen on ChatGPT Web.
This appears related to the report about widgets placed below model-generated text. This report adds a minimal reproduction and controlled comparisons. Please merge if keeping the evidence together is preferable.
Environment
- Reproduced September 10, 2026.
- Also reproduced on my physical Nothing phone while testing the reader in native ChatGPT. The exact phone model and its Android/ChatGPT versions have not yet been recorded in this report.
- Instrumented emulator: native ChatGPT Android 1.2026.244, versionCode 2624421; Android 17 / API 37, arm64, 1080 × 2424.
- The controlled SDK/canary comparison matrix below was run on the emulator, not on the physical phone. The physical-device observation confirms that the reader symptom is not limited to the emulator; it does not establish that every Android version/device is affected.
- Comparison: ChatGPT Web in Chrome, both Chat and Work modes.
- The failing minimal-canary path below is a Work conversation created on Web, then opened in native Android.
Reproduction
- Register a private MCP app with a UI-opening tool and a plain HTML resource. Our isolated canary tool returns a short text result and an empty
structuredContentobject, with no result metadata or application data. Keep the usual resource linkage on the tool descriptor. - Invoke it in ChatGPT Work on Web; confirm the inline canary is visible.
- Open that same conversation in native ChatGPT Android. The canary renders inline.
- Tap the canary’s Fullscreen button, which calls
window.openai.requestDisplayMode({ mode: "fullscreen" }).
Expected: the same HTML appears in fullscreen.
Actual: a blank fullscreen surface (black in the tested dark theme), with the host composer still visible. The native accessibility tree exposes no WebView or widget controls in the failed state. Android Back returns to the inline canary. Absence from the accessibility tree does not establish whether the WebView was destroyed, detached, or hidden.
Minimal widget
Normal document flow, default browser styles, two buttons, and a status paragraph. No dimensions or fullscreen-specific layout:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Minimal fullscreen canary</title>
</head>
<body>
<p>Minimal fullscreen canary v135</p>
<button type="button" value="fullscreen">Fullscreen</button>
<button type="button" value="inline">Inline</button>
<p id="status">Ready</p>
<script>
for (const button of document.querySelectorAll("button")) {
button.addEventListener("click", async () => {
const status = document.getElementById("status");
status.textContent = "Requesting " + button.value;
try {
await window.openai.requestDisplayMode({ mode: button.value });
status.textContent = button.value + " request returned";
} catch {
status.textContent = button.value + " request failed";
}
});
}
</script>
</body>
</html>
Controls already tested
| Control | Web result | Native Android result |
|---|---|---|
Full reader with @modelcontextprotocol/ext-apps 1.0.1 |
Five consecutive fullscreen/inline rendering cycles passed in Chat and Work | Saved Work conversation: first fullscreen entry blacked out; Back restored inline |
| Same reader with ext-apps 1.7.5 | Five consecutive rendering cycles passed in Chat and Work | Saved Work conversation: same blackout |
| SDK-free canary through a separate private app, new tool name and resource URI | Five Work rendering cycles passed | Same saved Work conversation blacked out |
Same literal canary with custom ui.domain / openai/widgetDomain omitted; actual default OpenAI sandbox origin verified |
Five Work rendering cycles passed | Still blacked out; Back restored inline |
For the full-reader comparison, the actual loaded JavaScript module was hash-verified on each test surface: these were not just package.json changes or unverified stale launches. Both the MCP Apps SDK display-mode request and the window.openai compatibility API have produced the Android failure during this investigation. The SDK-free control above uses only window.openai.
Important placement caveat
Android Chat is not uniformly broken. One saved Web Chat reader passed five native fullscreen round trips; that reader appeared above the response toolbar. Another saved Web Chat reader appeared below the toolbar and blacked out. The failing Work canaries also appeared below the completed answer/toolbar.
This resembles the linked report, but placement and creation path were not independently controlled, so I am not claiming a proven race condition or attributing the differing Chat results to SDK version. Nor do Web rendering passes mean every aspect of the full reader is bug-free; the bare canary is the strongest isolation here.
Questions for the Apps SDK / Android team
- Is there a known Android fullscreen attachment/lifecycle issue when the widget appears after the answer or response toolbar?
- Is additional resource metadata or initialization required even for this SDK-free, data-free document?
- What supported diagnostic would distinguish a hidden/detached fullscreen WebView from a widget-side rendering failure?
The evidence points toward the host transition/placement path, but a concrete integration requirement we have missed would be useful. Private endpoints and conversation identifiers are intentionally omitted from this public report.