Skip to content

fix(web): size the app to the dynamic viewport on mobile Safari - #3647

Open
PiedPiper911 wants to merge 1 commit into
teableio:developfrom
PiedPiper911:fix/ipad-safari-viewport-height
Open

PiedPiper911 wants to merge 1 commit into
teableio:developfrom
PiedPiper911:fix/ipad-safari-viewport-height

Conversation

@PiedPiper911

Copy link
Copy Markdown

Closes #3642

Problem

On mobile Safari (iPad, and iPhone) the URL bar / toolbar are part of the viewport that 100vh resolves against, so containers sized with h-screen / min-h-screen end up taller than the actually visible area. The app then scrolls as a document: with the toolbar visible the sidebar footer (user avatar + notifications) sits below the fold, and scrolling the browser chrome away pushes the top bar out of view instead.

Fix

Use the dynamic viewport unit (100dvh — Tailwind h-dvh / min-h-dvh) for the layout and full-height page containers, so their height tracks the visible viewport as the browser chrome animates:

  • components/layout/MainLayout.tsx — the app shell
  • features/app/layouts/SpaceLayout.tsx, SettingLayout.tsx — the #portal layouts
  • features/auth/components/LayoutMain.tsx, features/auth/pages/LoginPage.tsx, features/app/waitlist/WaitlistPage.tsx, features/app/blocks/share/... — full-height auth / waitlist / share pages
  • styles/global.css — the top-banner compensation rules are keyed on .h-screen / .min-h-screen and subtract --teable-top-banner-height; they are updated to the new class names and unit so the banner offset keeps working

Why dvh

dvh is supported by iOS Safari 15.4+, Chrome 108+ and Firefox 101+ (≈97% global baseline), and this repo already uses dvh units elsewhere (packages/sdk, packages/ui-lib), so this follows existing practice rather than introducing a new convention.

Notes

  • Desktop behaviour is unchanged — dvh equals vh when there is no dynamic browser chrome.
  • Scoped to viewport-sized layout containers; h-screen inside individual components is left as-is.
  • I could not run the visual check on an iPad from this environment — verified by diff inspection against the reported symptoms. Happy to adjust if you prefer to keep vh as a fallback declaration.

On mobile Safari the URL bar/toolbar are included in the 100vh calculation, so the
app was taller than the visible viewport: the page scrolled as a document and the
sidebar footer (user avatar / notifications) sat below the fold. Switching the
layout containers to the dynamic viewport unit (100dvh) keeps the app exactly the
height of the visible viewport while the browser chrome animates.

Closes teableio#3642
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@PiedPiper911

Copy link
Copy Markdown
Author

Added a local build check to confirm these utilities are generated by the Tailwind version this repo pins (tailwindcss: 3.4.1, per apps/nextjs-app/package.json):

.h-dvh        { height: 100dvh }
.min-h-dvh    { min-height: 100dvh }
.h-screen     { height: 100vh }
.min-h-screen { min-height: 100vh }

So h-dvh / min-h-dvh are first-class utilities here — no plugin or config change needed, and the diff stays a pure class-name swap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

App layout exceeds viewport height (iPad/Safari)

2 participants