Heuristic:DevExpress Testcafe Window Resize Correction
| Knowledge Sources | |
|---|---|
| Domains | Browser_Automation, Testing |
| Last Updated | 2026-02-12 03:30 GMT |
Overview
Browser windows require a two-pass resize: first to switch from maximized to normal mode, then to set the correct client area size, compensating for border differences.
Description
Browser windows have different border sizes in maximized and normal modes. When TestCafe needs to resize a browser to specific dimensions, it must first ensure the window is in normal (non-maximized) mode. The first resize operation forces the window out of maximized state, and the second resize sets the target client area dimensions. A 100x100 pixel difference is used for the initial resize to ensure the mode switch triggers. Additionally, the browser provider includes a 2-second opening delay after launch to allow the browser to fully initialize before attempting resize operations.
Usage
This heuristic explains why browser resize may appear to happen twice during test startup. It also explains why window dimensions may be briefly incorrect between the two resize operations. If tests rely on exact viewport dimensions from the very first moment, be aware of this initialization sequence. The 2-second opening delay and dual resize add up to the total browser initialization time.
The Insight (Rule of Thumb)
- Action: No configuration needed; the two-pass resize is automatic. Set target dimensions via `t.resizeWindow(width, height)` or the `--window-size` CLI flag.
- Value: Initial resize offset: 100x100 pixels. Browser opening delay: 2000ms.
- Trade-off: The dual resize adds a small startup delay but ensures accurate client area dimensions regardless of the initial window state.
Reasoning
Operating systems render window borders (title bar, frame) differently for maximized vs normal windows. On Windows, maximized windows have no visible border; on macOS, the title bar height changes. If the browser starts maximized (common in some CI environments), a single resize to the target dimensions would produce incorrect client area size because the browser would use maximized-mode border calculations. The first resize forces the window manager to switch to normal mode with its standard borders, and the second resize can then accurately calculate the chrome (border) offset.
Code Evidence
Resize difference constant from `src/browser/provider/index.ts:27-30`:
const RESIZE_DIFF_SIZE = {
width: 100,
height: 100,
};
Browser opening delay from `src/browser/provider/index.ts:25`:
const BROWSER_OPENING_DELAY = 2000;
HACK comment explaining the dual resize from `src/browser/provider/index.ts:67-69`:
// HACK: The browser window has different border sizes in normal and maximized modes. So, we need to be sure that the window is
// not maximized before resizing it in order to keep the mechanism of correcting the client area size working. When browser is started,
// we are resizing it for the first time to switch the window to normal mode, and for the second time - to restore the client area size.