Kiosk screen content cut off at the bottom: fix the page

Why does my kiosk screen cut off content at the bottom?

The page is taller than the browser window, so the last rows of content sit past the bottom edge of the screen, and no kiosk switch, resolution setting or cable will bring them back while the page stays that size.

The number that governs the whole fault is the viewport height. A 1920 × 1080 panel at 100 percent zoom offers 1080 CSS pixels. Stack 1176 pixels of blocks and the bottom 96 pixels are off-screen; the browser keeps them rendered, just past the edge. Kiosk mode hides the scrollbars, often with the --hide-scrollbars switch, so there is no scrollbar to warn you.

The same page in an office browser looks fine because a windowed browser gives you scrollbars, and the overflow reads as scrolling. On the kiosk it reads as missing content. Measure, and the argument ends: the browser's developer tools report the page height in CSS pixels, and the only number that matters is how far it exceeds 1080.

What does each symptom point to?

Each symptom points to one side of the chain: a cutoff that survives a plain full-screen window names the page, one that follows the screen to other monitors names the display, and one that appears after a resolution change names the compositor.

• Bottom rows missing at native 1920 × 1080, and a plain F11 full-screen window reproduces it: the page is the suspect, and the kiosk switches are cleared because they never ran in that test.
• 80 percent zoom brings back the short blocks but the tall ones still vanish: fixed-height blocks sized beyond the zoomed viewport, which holds 1350 CSS pixels at that setting.
• The same URL behaves on an office PC: the windowed browser there shows scrollbars, so the overflow appears as scrolling instead of missing content.
• Every page is cut on every screen you try: start in the monitor's picture menu, because a scaling mode crops edges with no browser involved.
• The cutoff appears after a monitor change, screen blanking or a suspend and resume: documented compositor behavior on Wayland, covered further down.

How do I rule out the screen and the kiosk flags?

Two checks take under ten minutes: confirm the panel shows 1:1 pixels at its native 1920 × 1080, then load the page in a plain full-screen window with none of the kiosk switches; if the cutoff is still there, the flags are cleared.

1. Set the display's picture size to its native, unscaled mode. A zoom, wide or overscan mode on the monitor crops the image before the browser is involved.
2. Confirm the signal: 1920 × 1080 at 60 Hz and a scale of 1.0. Under Wayland, the compositor's own display report prints both values; wlr-randr is the common tool on a single-board Linux build.
3. Try a second monitor of a different make. If the cutoff matches on both, the display is cleared and the measurement decides.
4. Drop the flags. Open the same URL in a plain window and press F11. If the bottom is still cut, the switch list is out of the case.
5. Measure. Open the developer tools, read the page height, and compare it to 1080.

This measure-first order works for browser pages inside HMI windows too; the walkthrough on diagnosing kiosk browser sizing in an HMI window follows the same steps.

Worked example: how many pixels is the page over?

On a 1920 × 1080 kiosk at 100 percent zoom the viewport is 1080 CSS pixels tall, so a page whose stacked blocks total 1176 pixels overflows by 96 pixels, and that is exactly the strip of footer your screen is eating.

Say the directory page is built like this, with heights read from the developer tools:

The arithmetic: 96 + 120 + (3 × 300) + 60 = 1176 px. The viewport holds 1080 px, so 1176 − 1080 = 96 px sit off-screen. That is the missing strip.

At 80 percent zoom the same panel offers 1080 ÷ 0.8 = 1350 CSS pixels. The 1176 px page now fits with 1350 − 1176 = 174 px spare, so the footer and the short logo blocks come back. A taller page measuring 1500 px does not: 1500 − 1350 = 150 px stay off the screen, which is why some blocks recover at 80 percent and others never do.

Zoom has its own cost: 16 px body text renders at 16 × 0.8 = 12.8 px at 80 percent, and the whole layout shrinks with it.

What should the web developer change?

The fix is page sizing: every block above the footer has to fit inside 1080 CSS pixels at 100 percent zoom, which usually means replacing hard-coded pixel heights with a layout that shares the viewport between the blocks.

Give the developer one requirement and three numbers. The requirement: the page fits 1080 CSS pixels at 100 percent zoom, full screen, no scrolling. The numbers: the measured page height, the 1080 px viewport, and the difference between them.

Two build patterns cause nearly all of these overflows. The first is a stack of blocks with hard-coded pixel heights that added up past the viewport on this screen. The second is a viewport-height unit, written 100 vh, applied to more than one stacked container; that pattern is a documented cause of pages that run past the screen, and the documented repair is to apply 100 vh to one outer container and lay the blocks out inside it.

You can name the offending block yourself. In the developer tools, delete elements one at a time and watch the reported page height; the block whose removal brings the total to 1080 px or under is the one to resize. Extensions exist that automate exactly this and name the element pushing the page taller.

If the screen shows an HMI page instead of a plain web page, the same viewport rule applies, and this guide to aligning objects to the bottom of a browser viewport shows the editor-side version of the fix.

Slide-based kiosks fail the same way with a different filename: a slide built at the wrong pixel size leaves part of the panel misused, and the fix for a signage screen showing slides in one corner covers that sizing mismatch.

Can the Wayland compositor put the window off-screen?

Yes, on Wayland a maximized window can sit partly off-screen after a monitor change, screen blanking or a suspend and resume, a documented compositor behavior, so a cutoff that starts after one of those events has a different cause and fix.

Wayland is designed to keep application windows ignorant of their exact placement on screen. Flags that try to pin a window to a coordinate, such as --window-position, assume control the design withholds, so they are the wrong lever on a Wayland session. Kiosk sessions under a lightweight Wayland compositor such as labwc also have a tracked history of window trouble after a resolution change.

Both look exactly like an oversize page from the outside, so the test is history. If the cutoff appeared right after a display change or a resume and other pages fit fine, relaunch the browser or restart the session before you measure. If every page fits and one page is cut, it is the page sizing, and the work goes back to the developer.

Keep the relaunch simple: a boot that lands straight in the browser with no dialogs is what the chromium kiosk autostart setup for Linux panels is for.

Who fixes what: the installer, the developer or the display menu?

Rule the display out in one menu, rule the flags out with one F11 press, measure the page in DevTools, and then hand the developer one number: how many CSS pixels the page is tall against the 1080 pixels the screen offers.

Recommendation: Keep the kiosk at 100 percent zoom and have the page rebuilt to fit 1080 CSS pixels. Use 80 percent zoom only as a same-day stopgap, and only when the page measures under 1350 px, because the blocks taller than that keep vanishing and the smaller text costs you reading distance on the floor.

Once the page measures 1080 px or under at 100 percent zoom, confirm it full screen on the kiosk itself. Then close out the physical side of the job: mount the panel square in its opening using the real cut-out sizes in the flush-mount cut-out guide, and if the kiosk is still being specified, pick the screen from the panel-mount display category.

Questions