On the school page, tapping the map band or the "View on map" link did nothing on iPhones: open() calls wrapperRef.current?.requestFullscreen?.(), and iOS Safari has no Element.requestFullscreen (fullscreen is video-only there), so the optional call silently no-ops.
When the Fullscreen API is missing — or its promise rejects — fall back to a fixed-position CSS overlay (data-fs-fallback, z-index 5000) driven by component state, with body scroll locked while open.
Native fullscreen path is unchanged; the Leaflet map re-measures through the shared isFullscreen flag either way.
New e2e journey deletes Element.prototype.requestFullscreen on a mobile viewport, opens the map, and asserts the fullscreen view opens and closes. It fails against the current production build, reproducing the report.
On the school page, tapping the map band or the "View on map" link did nothing on iPhones: `open()` calls `wrapperRef.current?.requestFullscreen?.()`, and iOS Safari has no `Element.requestFullscreen` (fullscreen is video-only there), so the optional call silently no-ops.
- When the Fullscreen API is missing — or its promise rejects — fall back to a fixed-position CSS overlay (`data-fs-fallback`, z-index 5000) driven by component state, with body scroll locked while open.
- Native fullscreen path is unchanged; the Leaflet map re-measures through the shared `isFullscreen` flag either way.
- New e2e journey deletes `Element.prototype.requestFullscreen` on a mobile viewport, opens the map, and asserts the fullscreen view opens and closes. It fails against the current production build, reproducing the report.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
iOS Safari has no Element.requestFullscreen (fullscreen is video-only),
so tapping the map band or 'View on map' silently did nothing on
iPhones. Fall back to a fixed-position CSS overlay driven by state when
the Fullscreen API is missing or its promise rejects, locking body
scroll while open. The Leaflet map already re-measures via the shared
isFullscreen flag. New e2e journey simulates the iOS condition by
deleting the API and asserts the overlay opens and closes; it fails
against the current production build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This PR adds an iOS-Safari-safe fallback for the school hero map's fullscreen toggle (CSS fixed-overlay driven by state instead of the missing Fullscreen API), with matching CSS and a new e2e test. The logic is sound: it correctly branches on el.requestFullscreen presence/rejection, restores body scroll on close, and the z-index/stacking math checks out against the rest of the app's CSS (no other modal is ever mounted on the school-detail page, so the 5000 z-index doesn't actually clash with anything). No correctness, security, or deploy/CI issues found.
🟡 Minor
nextjs-app/components/SchoolHeroMap.tsx: The CSS-overlay fallback path adds no Escape-key handler. Native requestFullscreen() gets Escape-to-exit for free from the browser, and the existing Modal component binds Escape explicitly, but this new fallback (used when requestFullscreen is absent or rejected) only exits via the visible close button, a minor keyboard/accessibility regression versus both of those patterns.
## 🤖 AI Code Review (Claude Code)
This PR adds an iOS-Safari-safe fallback for the school hero map's fullscreen toggle (CSS fixed-overlay driven by state instead of the missing Fullscreen API), with matching CSS and a new e2e test. The logic is sound: it correctly branches on `el.requestFullscreen` presence/rejection, restores body scroll on close, and the z-index/stacking math checks out against the rest of the app's CSS (no other modal is ever mounted on the school-detail page, so the 5000 z-index doesn't actually clash with anything). No correctness, security, or deploy/CI issues found.
### 🟡 Minor
- **nextjs-app/components/SchoolHeroMap.tsx**: The CSS-overlay fallback path adds no Escape-key handler. Native `requestFullscreen()` gets Escape-to-exit for free from the browser, and the existing `Modal` component binds Escape explicitly, but this new fallback (used when `requestFullscreen` is absent or rejected) only exits via the visible close button, a minor keyboard/accessibility regression versus both of those patterns.
tudor
merged commit 90f2a02e75 into main2026-07-05 20:52:32 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On the school page, tapping the map band or the "View on map" link did nothing on iPhones:
open()callswrapperRef.current?.requestFullscreen?.(), and iOS Safari has noElement.requestFullscreen(fullscreen is video-only there), so the optional call silently no-ops.data-fs-fallback, z-index 5000) driven by component state, with body scroll locked while open.isFullscreenflag either way.Element.prototype.requestFullscreenon a mobile viewport, opens the map, and asserts the fullscreen view opens and closes. It fails against the current production build, reproducing the report.🤖 Generated with Claude Code
cc5b6955d8tod52d384cf2🤖 AI Code Review (Claude Code)
This PR adds an iOS-Safari-safe fallback for the school hero map's fullscreen toggle (CSS fixed-overlay driven by state instead of the missing Fullscreen API), with matching CSS and a new e2e test. The logic is sound: it correctly branches on
el.requestFullscreenpresence/rejection, restores body scroll on close, and the z-index/stacking math checks out against the rest of the app's CSS (no other modal is ever mounted on the school-detail page, so the 5000 z-index doesn't actually clash with anything). No correctness, security, or deploy/CI issues found.🟡 Minor
requestFullscreen()gets Escape-to-exit for free from the browser, and the existingModalcomponent binds Escape explicitly, but this new fallback (used whenrequestFullscreenis absent or rejected) only exits via the visible close button, a minor keyboard/accessibility regression versus both of those patterns.