328773 2026-10-24 03:21:39 -0700 Support the Element Fullscreen API (requestFullscreen) for all web content on iPhone, not just <video> 2026-10-24 11:27:50 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build iPhone / iPad iOS 27 RESOLVED DUPLICATE 206854 P2 Enhancement --- 1 sreeharisureshmltr webkit-unassigned oldest_to_newest 2268735 0 sreeharisureshmltr 2026-10-24 03:21:39 -0700 SUMMARY On iPhone, a web page can't go full screen. Only <video> can, through the non-standard HTMLVideoElement.webkitEnterFullscreen(), which hands playback to the native player. The standard Fullscreen API (Element.requestFullscreen(), document.fullscreenEnabled, :fullscreen, fullscreenchange) doesn't seem to be available. This applies in Safari and, as far as I can tell, in every other iOS browser too, since they all use WebKit. According to MDN's browser compatibility data, the same API works for any element on other platforms: - Safari on macOS: supported since 16.4 (prefixed since 5.1) - Safari on iPadOS: supported since 16.4 (prefixed since 12), marked as partial with the note "Only available on iPad, not on iPhone." - Chrome on Android: supported since 71 - Firefox on Android: supported since 64 Source: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API#browser_compatibility I haven't personally tested all of these devices. Going by that data, iPhone is the main platform where a website can't use the whole screen, even though WebKit already ships the feature on iPad. Please consider enabling Element.requestFullscreen() on iPhone for any element, with the same user-gesture requirement and exit behaviour as the platforms where it's already supported. STEPS TO REPRODUCE 1. On an iPhone, open a page with the test case below in Safari, or in Chrome for iOS. 2. Note the value shown for fullscreenEnabled. 3. Tap "Go full screen". Test case: <!doctype html> <meta name="viewport" content="width=device-width,initial-scale=1,viewport-fit=cover"> <style> html, body { margin: 0; height: 100%; background: #111; color: #eee; font: 18px system-ui; } #app { height: 100%; display: grid; place-content: center; gap: 12px; text-align: center; } :fullscreen #status::after { content: " (in full screen)"; } </style> <div id="app"> <p id="status">fullscreenEnabled: <b id="enabled"></b></p> <button id="go">Go full screen</button> </div> <script> enabled.textContent = String(document.fullscreenEnabled); go.onclick = () => { const el = document.getElementById('app'); if (!el.requestFullscreen) return alert('requestFullscreen is not supported in this browser'); el.requestFullscreen({ navigationUI: 'hide' }) .then(() => console.log('entered')) .catch(e => alert('requestFullscreen failed: ' + e.message)); }; </script> EXPECTED document.fullscreenEnabled is true. The tap puts the page into full screen, the browser bars hide and the content fills the display. A system gesture exits. ACTUAL The page never goes full screen. Even at its most minimal, the browser keeps a small tab on screen: at the bottom of the screen in portrait, and at the top in landscape. The page can't remove it, so it never gets the whole display. Test case result: fullscreenEnabled shows [true/false], and tapping "Go full screen" [shows "requestFullscreen is not supported in this browser" / shows an error / does nothing]. Tested on: iPhone 17, iOS 27.0. USE CASES BLOCKED TODAY - Dashboards and always-on displays: status boards, clocks, smart-home panels and monitoring screens on a phone in a stand. For example, I'm building a dashboard for an iPhone on a desk stand. In landscape, the browser toolbar takes a large share of an already short screen. - Games: canvas and WebGL games have to give up screen space to browser bars. - Custom video players: webkitEnterFullscreen() swaps the site's own player for the native one. Custom controls, caption styling, overlays and interactive video are all lost. - Presentations: web presentation tools can't present full screen from a phone. - Reading: e-book readers, comics and documentation sites that want distraction-free reading. - Maps, and photo and 3D viewers: they need every pixel. - Accessibility: users with low vision benefit from the largest possible content area. WHY THE EXISTING WORKAROUNDS FALL SHORT - webkitEnterFullscreen() on <video>: video only, and the native player replaces the page, so the page can't be interacted with. - Safari's "Hide Toolbar" (page menu): the user has to find it in a menu, and the page can't trigger it. It doesn't remove the bars: a strip with the domain name stays, and the toolbar comes back on a tap near the edge. - Add to Home Screen (standalone web app): requires a manual install that most users don't know about, and pages can't prompt for it. The installed app has separate cookies and storage from the browser, so users have to sign in again. It doesn't help normal in-browser use. - Scrolling to collapse the toolbar: the compact address bar stays. It doesn't work for pages that don't scroll, like dashboards, games and maps. POSSIBLE SAFEGUARDS The main concern is probably spoofing: a full-screen page drawing fake system UI or a fake address bar. MDN notes that on iPad, full screen "shows an overlay button which can not be disabled" and that "swiping down exits fullscreen mode". Bringing the same iPad behaviour to iPhone would be a big improvement, even with those limits. I'm not a browser security expert, but these seem like reasonable protections: 1. User gesture required: requestFullscreen works only within a user gesture, as the spec already requires. 2. Notice on entry: a system overlay shows the site's domain and how to exit. 3. System-controlled exit: a gesture the page can't block, such as a swipe down from the top, always exits. 4. Automatic exit: full screen ends on app switch, tab switch, navigation to another site, or an incoming call. 5. Iframes: only with allow="fullscreen", per the spec. SPEC REFERENCE https://fullscreen.spec.whatwg.org/ 2268736 1 sreeharisureshmltr 2026-10-24 03:27:27 -0700 This looks like a duplicate of bug 206854. 2268816 2 ap 2026-10-24 11:27:50 -0700 *** This bug has been marked as a duplicate of bug 206854 ***