In Selenium, what is the difference between manage().window().maximize(), fullscreen() and minimize()?

## Three commands, three different outcomes Selenium 4's `WebDriver.Window`, reached through `driver.manage().window()`, exposes three sizing commands beside the explicit `setSize`. Each maps to its own **W3C WebDriver** command, so each is implemented by the driver and ultimately by the browser and the host operating system. | Call | W3C command | What happens to the window | Browser chrome | |---|---|---|---| | `maximize()` | Maximize Window | grows to the desktop's available working area | still visible | | `fullscreen()` | Fullscreen Window | enters the browser's full-screen mode | hidden | | `minimize()` | Minimize Window | removed from the visible display | not shown at all | The spec wording matters here: maximize and minimize **invoke the window manager's own operation**. They are requests to the desktop environment, not arithmetic Selenium performs. ## maximize - Fills the space the desktop leaves free, so a taskbar or dock reduces it. - The resulting size depends entirely on the host's screen, so the same call produces different widths on your laptop, a colleague's external monitor and a build agent. - With no window manager - a headless browser, or a machine with no display server - there is nothing to maximise against, so the call may do nothing useful. ## fullscreen - Equivalent to the browser's own full-screen mode, the one a user reaches with a keyboard shortcut. - The tab strip, address bar and bookmarks are hidden, so the page gains that height. - Useful when a stock-count grid's sticky footer totals are pushed below the fold by chrome, and you want the page to have every available pixel. - Still not a **stated** size: it is the display's size minus nothing, which is a different number on every machine. ## minimize - Hides the window from the display while the **session stays alive** - this is not `close()` and not `quit()`, and the window handle remains valid. - The page may be treated as hidden by the browser, so rendering-dependent behaviour changes. - That makes it a poor thing to call mid-test: an element the driver would call displayed can behave differently, and animations or lazily rendered rows may not advance. - Its honest use is at the edges - getting a browser out of the way on a shared desktop - not inside a scenario. ## What this means for a warehouse stock-count grid Suppose the count sheet shows a variance column only above a breakpoint, and the suite opens with `maximize()` because that is what the first test author wrote. On the author's monitor the window lands at 2560 px and the column renders. On a 1366 px build agent it does not, and the run fails on a locator that is completely correct. The repair is to stop asking the host how big the window should be: 1. Pick the width the suite claims to test and state it once. 2. Apply it with `setSize(new Dimension(1600, 1200))`, or at launch through the browser's window-size argument. 3. Read the viewport back at the start of the run and fail loudly if it is not what you asked for. 4. Keep `maximize()` for exploratory, human-watched runs where reproducibility is not the point. ```java WebDriver.Window window = driver.manage().window(); window.setSize(new Dimension(1600, 1200)); System.out.println(window.getSize()); ``` ## Availability is not guaranteed These commands are optional in a way `setSize` largely is not. A remote end that cannot manipulate the window - some mobile and embedded contexts - answers with an **unsupported operation** error rather than silently succeeding. That is another reason a suite that depends on a specific rendering should express the width it needs, and treat maximize and fullscreen as conveniences rather than as part of its contract. ## Reading back what the window actually became Because all three commands delegate to something outside your test - a window manager, a display, a browser mode - none of them tells you the result. `driver.manage().window().getSize()` does, and it is the only honest way to know what a run rendered at. 1. Call the sizing command, whichever one you chose. 2. Read the rect back with `getSize()` and log the returned `Dimension` beside the run's other setup output. 3. If the run is layout-sensitive, compare that against the width the suite claims to test and fail early rather than at the first missing element. - A maximised window on a build agent and a maximised window on a workstation will log two different numbers, which is the whole argument against maximising in the first place. - A fullscreen window logs the display's size, so the log doubles as a record of what hardware the run got. - A minimised window still answers `getSize()`, because the rect survives while the window is hidden. The habit costs one line and converts a class of confusing layout failures into a number sitting at the top of the run log.