skip to content

A Selenium suite sets the window to 1280 wide, yet a min-width 1280px media query never matches. Why?

level: seniorimportance: nice to knowfreq 41%

answer

  1. Requested width is not rendered width
  2. The browser frame is part of the number
  3. Something vertical steals a slice of width
  4. outerWidth versus innerWidth
  5. Missing the breakpoint by a scrollbar

basics

~20 s

Selenium sizes the whole browser window, not the page. Browser chrome and the vertical scrollbar come out of that number, so a 1280-wide window lays the page out in slightly less than 1280 CSS pixels and the query misses.

solid answer

~40 s

`manage().window().setSize(new Dimension(1280, 800))` sets the **outer** window rect - the same measurement the page sees as `window.outerWidth` - and that number includes the browser's own chrome and window frame. The CSS viewport the page lays out in is smaller: chrome takes height, and a classic vertical scrollbar takes width. So a warehouse stock-count grid whose wide layout is gated on `min-width: 1280px` sits just under the threshold and renders its narrow variant. The fix is to size for the viewport you need, not the window: ask for a comfortably larger window, then read `window.innerWidth` back and assert on that. Treat the requested rect as an input and the measured viewport as the fact.

code

java · 7 lines
java
WebDriver driver = new ChromeDriver();
driver.manage().window().setSize(new Dimension(1280, 800));
driver.get("https://warehouse.example.com/counts/2026-09/aisle-14");
Dimension outer = driver.manage().window().getSize();
long inner = (long) ((JavascriptExecutor) driver).executeScript("return window.innerWidth;");
System.out.println("window " + outer.getWidth() + " px, viewport " + inner + " px");
driver.quit();

go deeper

for a junior

Remember that the size you ask Selenium for is the whole browser window, and the page always gets less than that. If a layout looks wrong, print what the page reports rather than trusting the number in the test.

for a middle

Explain the two measurements and what sits between them: browser chrome takes height, a classic scrollbar takes width, and only the CSS viewport drives media queries. Know which call reads which number.

for a senior

Demonstrate the diagnosis on a real failure: measured viewport against requested rect, gap size telling you whether it is a scrollbar or a later resize. Then harden the suite so a breakpoint is never decided by a scrollbar.

for a principal

Own the convention that a suite states the viewport it tests, verifies it, and never sits on a breakpoint. Decide how that check is shared across suites so every team inherits it instead of rediscovering this failure.

## Two measurements, one number in your test The W3C **window rect** that Selenium reads and writes describes the **whole browser window** as the operating system sees it. The specification ties its `width` and `height` to `window.outerWidth` and `window.outerHeight`. The page, meanwhile, lays itself out in the **CSS viewport**, reported as `window.innerWidth` and `window.innerHeight`. They are never the same number on a desktop browser, and the difference is where this bug lives. | | `manage().window().getSize()` | `window.innerWidth` / `innerHeight` | |---|---|---| | What it measures | the whole browser window | the area the page lays out in | | Web-platform equivalent | `window.outerWidth` / `outerHeight` | the CSS viewport | | Includes browser chrome | yes | no | | Includes a classic scrollbar | yes | no | | What media queries follow | nothing | this one | ## Where the missing pixels go - **Vertical chrome** - the tab strip, address bar and any bookmarks bar - comes out of the height, and it is not a constant: a profile with an extra toolbar shows a different viewport height from a clean one. - A **classic vertical scrollbar** comes out of the width whenever the page is tall enough to scroll, which a stock-count grid with several hundred bins always is. - The **window frame** drawn by the operating system can take a further pixel or two on each edge, and differs between platforms. - **Overlay** scrollbars, used on some platforms and in some browser configurations, take nothing at all - so the same test can be off by a scrollbar's width on one machine and exact on another. That last point is the reason this reproduces on a build agent and not on the author's machine, or the other way round. ## The warehouse stock-count grid, concretely The grid is styled so that the variance column appears only inside `@media (min-width: 1280px)`. The suite sets a 1280-wide window, believing it has met the breakpoint exactly. With a classic scrollbar present the page lays out in a little under 1280 CSS pixels, the query does not match, the variance column is absent, and the test fails on a locator that is entirely correct. The symptom is maximally misleading: the requested number matches the breakpoint, so the numbers in the code look right, and the failure looks like a locator or an application bug. ## Diagnosing it in one step When a layout-sensitive test fails, do not reason about the number you set - read the number the page got: 1. Read the window rect with `driver.manage().window().getSize()` and note the width. 2. Read the viewport by executing `return window.innerWidth;` in the page. 3. Compare them. A gap of roughly a scrollbar's width on a page that scrolls is this bug; a much larger gap means something else resized the window after your call. 4. Compare the viewport against the breakpoint, not against the requested window size. ```java Dimension outer = driver.manage().window().getSize(); long inner = (long) ((JavascriptExecutor) driver) .executeScript("return window.innerWidth;"); System.out.println("window " + outer.getWidth() + " px, viewport " + inner + " px"); ``` ## Sizing so this cannot bite again - **Never request a window width equal to a breakpoint.** Ask for a width comfortably above it, so a scrollbar cannot decide the outcome. - **Assert the viewport, not the request.** One check at the start of the run that `window.innerWidth` meets the width the suite claims turns a silent layout switch into an explicit failure with a useful message. - **Expect height to vary more than width**, because chrome height is the least predictable part and differs by browser and profile. - **Keep the same target in headed and headless runs**, so a developer reproducing a pipeline failure sees the same layout branch. ## Where this leaves the API None of this makes `setSize` wrong; it makes it precise about something other than what a responsive page cares about. Selenium controls the window because that is what the WebDriver protocol owns - the browser is the thing it drives. The CSS viewport is a property of the page, so the page is where you read it from. Holding those two apart, and asserting on the second, is the whole of the discipline.

  • How would you pick window sizes so a scrollbar can never change which layout renders?
    Never request a width that sits on a breakpoint. Choose a width well inside the band you mean to test - say 1440 for a 1280 breakpoint - so a scrollbar's width cannot cross the threshold. Then assert `window.innerWidth` at the start of the run, so if anything does move the window the failure names the real cause.
  • The window rect looks correct but the viewport is hundreds of pixels short. What does that suggest?
    Not a scrollbar - that gap is far too large. Something resized the window after your call, or the browser could not honour the request because the host screen is smaller than what you asked for. Log the rect immediately after setting it and again just before the failing step, so you can tell which of the two happened.
  • Why does the height gap vary more between machines than the width gap?
    Width usually loses only a scrollbar, and only when the page scrolls. Height loses the browser chrome, which is not a fixed quantity: a bookmarks bar, an extension toolbar, an update banner or a different browser version all change it. If a test depends on how much of a page is above the fold, measure the viewport height rather than assuming it.

It is like ordering a 1280 mm shelving unit for an aisle and then discovering the shelf boards are narrower than that: the frame you specified is part of the number you asked for, not part of the space you get to fill.

saying these in an interview costs you the question

  • Assumes setSize sets the CSS viewport the page lays out in
  • Requests a window width exactly equal to a CSS breakpoint
  • Thinks media queries stop re-evaluating after the page has loaded
  • Believes the chrome height is the same on every machine
  • Asserts on the size requested instead of the size measured