In Selenium's Java client, how do you set and read the browser window's size and position?

juniorshould knowfreq 63%

answer

One entry point off manage()
Two value objects, not four integers
Width and height travel together
X and y travel together
One rect behind all four calls

basics

~10 s

Go through driver.manage().window(). Call setSize with a Dimension of width and height, and setPosition with a Point of x and y. Read them back with getSize and getPosition, which return the same two types.

solid answer

~30 s

Everything goes through driver.manage().window(), which returns a WebDriver.Window. Size uses org.openqa.selenium.Dimension: setSize(new Dimension(1440, 900)) writes it and getSize() returns one with getWidth() and getHeight(). Position uses org.openqa.selenium.Point: setPosition(new Point(0, 0)) writes it and getPosition() returns one with getX() and getY(), measured from the screen's top-left corner to the window's top-left corner. All four calls travel over the same pair of W3C commands, Get Window Rect and Set Window Rect, so the driver reads or writes one rectangle of x, y, width and height. Setting a fixed size is what makes a warehouse stock-count grid render the same layout on every machine.

Everything goes through `driver.manage().window()`, which returns a `WebDriver.Window`. Size uses `org.openqa.selenium.Dimension`: `setSize(new Dimension(1440, 900))` writes it and `getSize()` returns one with `getWidth()` and `getHeight()`. Position uses `org.openqa.selenium.Point`: `setPosition(new Point(0, 0))` writes it and `getPosition()` returns one with `getX()` and `getY()`, measured from the screen's top-left corner to the window's top-left corner. All four calls travel over the same pair of W3C commands, Get Window Rect and Set Window Rect, so the driver reads or writes one rectangle of x, y, width and height. Setting a fixed size is what makes a warehouse stock-count grid render the same layout on every machine.

code

java · 8 lines

java

WebDriver driver = new ChromeDriver();
driver.get("https://warehouse.example.com/counts/2026-09/aisle-14");
driver.manage().window().setPosition(new Point(0, 0));
driver.manage().window().setSize(new Dimension(1440, 900));
Dimension size = driver.manage().window().getSize();
Point position = driver.manage().window().getPosition();
System.out.println(size.getWidth() + "x" + size.getHeight() + " at " + position.getX() + "," + position.getY());
driver.quit();

go deeper

for a junior

Be able to write the calls from memory: manage().window(), then setSize with a Dimension and setPosition with a Point, and the matching getters. Know which of the two types carries width and height.

for a middle

Explain that all four calls are one W3C window rect underneath, so reading size and position separately costs two round trips, and that the browser can return a rect different from the one requested.

for a senior

Show where this belongs in a suite: size set once per session in setup, the returned value logged with failure evidence, and position left alone unless a specific multi-display reproduction needs it.

for a principal

Own where the window geometry a suite runs at is declared, so it is one decision rather than a line copied into every setup method, and make sure a run that does not get the geometry it asked for says so.

The one entry point

Window control in Selenium 4's Java client hangs off driver.manage(), which returns a WebDriver.Options. Calling .window() on that gives you a WebDriver.Window, and every size and position call lives there. There is no separate driver method and no helper class to construct.

java

WebDriver.Window window = driver.manage().window();
window.setSize(new Dimension(1440, 900));
window.setPosition(new Point(0, 0));

Holding the Window in a local is optional; chaining driver.manage().window().setSize(...) is the more common spelling in test code.

Two value objects, not four integers

The Java client uses two small immutable value types from org.openqa.selenium, and mixing them up is the usual first mistake.

Type	Constructor	Readers	Used by
`Dimension`	`new Dimension(width, height)`	`getWidth()`, `getHeight()`	`setSize`, `getSize`
`Point`	`new Point(x, y)`	`getX()`, `getY()`	`setPosition`, `getPosition`

Both constructors take plain integers in pixels, in that order.
Both types are value objects with sensible equals and toString, so a Dimension prints readably in a log line or an assertion failure.
Point measures the window's top-left corner relative to the screen's top-left corner, so new Point(0, 0) parks the window in the corner of the primary display.
Negative coordinates are legal and are how a window is moved onto a second display arranged to the left of the primary one.

What travels over the wire

All four calls are the same W3C WebDriver pair underneath:

getSize() and getPosition() both issue Get Window Rect, which answers with one object carrying x, y, width and height. The client then hands you the half you asked for.
setSize() and setPosition() both issue Set Window Rect with the members you are changing.

Two consequences follow from that. First, reading size and position separately is two round trips to the browser for one rectangle, which is worth knowing when a helper reads both in a loop. Second, a remote end that cannot manipulate its window - some non-desktop contexts - answers with an unsupported operation error rather than quietly doing nothing.

Sizing a warehouse stock-count grid run

A suite that walks a warehouse stock-count sheet needs the same layout on every machine, because the count sheet shows its variance column only above a breakpoint. One call in setup is enough:

java

driver.manage().window().setSize(new Dimension(1440, 900));

Position matters far less, and most suites never touch it. Its honest uses are narrow:

Parking a headed run at a known corner so a human watching several browsers can tell them apart.
Moving a window off a display that is about to be used for something else.
Reproducing a defect that only appears when the window straddles two monitors.

It has no effect on layout at all, because the page never learns where its window sits.

Reading back, and why you should

getSize() returns what the browser actually settled on, which is not always what you requested - a host screen smaller than the request, or a window manager with its own opinion, will hand back something different. So the useful habit is to write the size and then log or assert the value that comes back:

Set the size once in setup rather than per test, since the window persists for the session.
Log the returned Dimension alongside the failure evidence, so a report shows the geometry the run used.
Remember that getSize() reports the whole window, chrome included, not the area the page lays out in - so it confirms your request landed, not that the page got a particular CSS width.

That last distinction is the one juniors are most often asked to state out loud, and it costs nothing to check.

What the window rect does not control

A surprising amount of test-suite folklore attaches things to these four calls that they have nothing to do with. The rect is the browser window's geometry on the screen, and that is all it is.

It does not set the page's scroll position. Moving a window with setPosition leaves the stock-count grid scrolled exactly where it was.
It does not set the CSS viewport directly; the viewport is what remains after browser chrome and any scrollbar.
It does not change the browser's zoom level or the device pixel ratio, so a page rendered at a given width still renders at whatever scale the browser was configured with.
It says nothing about the document's own dimensions - a count sheet with four hundred bins is far taller than any window you can ask for.

Keeping those apart is what stops a test from setting a window size and then asserting something the window size was never going to change.

## The one entry point Window control in Selenium 4's Java client hangs off `driver.manage()`, which returns a `WebDriver.Options`. Calling `.window()` on that gives you a `WebDriver.Window`, and every size and position call lives there. There is no separate driver method and no helper class to construct. ```java WebDriver.Window window = driver.manage().window(); window.setSize(new Dimension(1440, 900)); window.setPosition(new Point(0, 0)); ``` Holding the `Window` in a local is optional; chaining `driver.manage().window().setSize(...)` is the more common spelling in test code. ## Two value objects, not four integers The Java client uses two small immutable value types from `org.openqa.selenium`, and mixing them up is the usual first mistake. | Type | Constructor | Readers | Used by | |---|---|---|---| | `Dimension` | `new Dimension(width, height)` | `getWidth()`, `getHeight()` | `setSize`, `getSize` | | `Point` | `new Point(x, y)` | `getX()`, `getY()` | `setPosition`, `getPosition` | - Both constructors take **plain integers in pixels**, in that order. - Both types are value objects with sensible `equals` and `toString`, so a `Dimension` prints readably in a log line or an assertion failure. - `Point` measures the window's **top-left corner** relative to the screen's top-left corner, so `new Point(0, 0)` parks the window in the corner of the primary display. - Negative coordinates are legal and are how a window is moved onto a second display arranged to the left of the primary one. ## What travels over the wire All four calls are the same **W3C WebDriver** pair underneath: 1. `getSize()` and `getPosition()` both issue **Get Window Rect**, which answers with one object carrying `x`, `y`, `width` and `height`. The client then hands you the half you asked for. 2. `setSize()` and `setPosition()` both issue **Set Window Rect** with the members you are changing. Two consequences follow from that. First, reading size and position separately is two round trips to the browser for one rectangle, which is worth knowing when a helper reads both in a loop. Second, a remote end that cannot manipulate its window - some non-desktop contexts - answers with an **unsupported operation** error rather than quietly doing nothing. ## Sizing a warehouse stock-count grid run A suite that walks a warehouse stock-count sheet needs the same layout on every machine, because the count sheet shows its variance column only above a breakpoint. One call in setup is enough: ```java driver.manage().window().setSize(new Dimension(1440, 900)); ``` Position matters far less, and most suites never touch it. Its honest uses are narrow: - Parking a headed run at a known corner so a human watching several browsers can tell them apart. - Moving a window off a display that is about to be used for something else. - Reproducing a defect that only appears when the window straddles two monitors. It has no effect on layout at all, because the page never learns where its window sits. ## Reading back, and why you should `getSize()` returns what the browser actually settled on, which is not always what you requested - a host screen smaller than the request, or a window manager with its own opinion, will hand back something different. So the useful habit is to write the size and then log or assert the value that comes back: - Set the size once in setup rather than per test, since the window persists for the session. - Log the returned `Dimension` alongside the failure evidence, so a report shows the geometry the run used. - Remember that `getSize()` reports the **whole window**, chrome included, not the area the page lays out in - so it confirms your request landed, not that the page got a particular CSS width. That last distinction is the one juniors are most often asked to state out loud, and it costs nothing to check. ## What the window rect does not control A surprising amount of test-suite folklore attaches things to these four calls that they have nothing to do with. The rect is the browser window's geometry on the screen, and that is all it is. - It does not set the **page's scroll position**. Moving a window with `setPosition` leaves the stock-count grid scrolled exactly where it was. - It does not set the **CSS viewport** directly; the viewport is what remains after browser chrome and any scrollbar. - It does not change the browser's **zoom level** or the device pixel ratio, so a page rendered at a given width still renders at whatever scale the browser was configured with. - It says nothing about the **document's** own dimensions - a count sheet with four hundred bins is far taller than any window you can ask for. Keeping those apart is what stops a test from setting a window size and then asserting something the window size was never going to change.

What does the origin of the coordinates handed to setPosition mean, and can they be negative?
The `Point` is the window's top-left corner measured from the screen's top-left corner, in pixels. Negative values are legal: they place the window on a display arranged above or to the left of the primary one. Position never affects layout, so a responsive page renders identically wherever the window sits.
Why might getSize() return something other than the Dimension you just set?
Because the browser and the host get the final say. A requested size larger than the screen, a window manager that constrains or snaps windows, or a context that cannot be resized at all will all produce a different rect. That is why reading the value back - and logging it with your failure evidence - beats assuming the request landed.

saying these in an interview costs you the question

Passes a Point to setSize or a Dimension to setPosition
Expects setSize to accept two int arguments directly
Thinks setPosition changes the page's scroll offset
Believes window position affects how a responsive page renders
Assumes getSize always echoes back the exact size requested

In Selenium's Java client, how do you set and read the browser window's size and position?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The one entry point

Two value objects, not four integers

What travels over the wire

Sizing a warehouse stock-count grid run

Reading back, and why you should

What the window rect does not control

▾common follow-ups2 questions

▾red flags5 flags

The one entry point

Two value objects, not four integers

What travels over the wire

Sizing a warehouse stock-count grid run

Reading back, and why you should

What the window rect does not control

answer

go deeper