{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreic75yierqgaiarpbzxjat55jk5kqwpdnp3xfiym7oemnbi7jlppwy",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mkjl7zrzox72"
  },
  "path": "/t/widget-fullscreen-bottom-clearance-how-to-distinguish-native-mobile-app-vs-mobile-web-browser/1379908#post_1",
  "publishedAt": "2026-04-28T01:21:49.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "chatgpt.com"
  ],
  "textContent": "I’m building a fullscreen widget (using requestDisplayMode({ mode: ‘fullscreen’ })) and need to handle bottom clearance differently depending on the hosting context:\n\n**Native mobile app (iOS/Android):** The WebView sits above the native chat bar. No extra bottom padding needed — the widget fills exactly the space it’s allocated. Only env(safe-area-inset-bottom) is required.\n\n**Mobile web browser (chatgpt.com in Chrome/Safari):** The widget iframe receives the full viewport height, but the chatgpt.com DOM input composer (~102px) visually overlays the bottom of the widget. Without extra bottom padding, sticky footers and CTAs end up hidden behind the composer.\n\n**The problem:** I cannot find any SDK signal to distinguish these two cases. Both contexts:\n\n  * Set window.openai.userAgent.device.type === ‘mobile’ via the openai:set_globals event\n\n  * Have identical navigator.userAgent strings (both are Chrome on Android)\n\n  * Do not include the Android WebView `wv` UA marker (modern Chrome-based WebViews omit it)\n\n\n\n\nThe widget cannot inspect the parent frame DOM to detect the composer element.\n\n**Questions:**\n\n  1. Is there an existing window.openai property or `set_globals` payload field that identifies **native app** vs **web browser** context?\n\n  2. Is window.openai.displayMode or any other property reliable for this distinction?\n\n  3. If not, would OpenAI consider adding a window.openai.hostContext or similar field (e.g. `'native-app' | 'web'`) to the SDK? This would unlock proper layout handling for fullscreen widgets on mobile.\n\n\n\n\n**Current workaround attempted:**\n\n  * UA heuristics (`/\\bwv\\b/`, /Version\\/\\d/ on Android) — fails for modern Chrome-based WebViews\n\n  * device.type === ‘mobile’ from `set_globals` — same value in both contexts, can’t distinguish\n\n\n\n\nAny guidance appreciated!",
  "title": "Widget fullscreen bottom clearance: how to distinguish native mobile app vs mobile web browser?"
}