🖥️ Responsive or Broken? How do you handle different screen resolutions?

Web Testing
1

Hi Everyone!

We’ve all experienced that “it works on my machine” moment, only to find out the test fails in the CI/CD pipeline or on a colleague’s laptop because the resolution is different.

Elements overlap, buttons hide behind floating footers, or—my personal favorite—the “Click” hits the wrong coordinates because of browser scaling.

I’m curious to know how this community ensures their Katalon tests are truly resolution-independent.

A few ways I’ve seen people handle this:

  • The “Maximize” Approach: Simply using WebUI.maximizeWindow() at the start of every script. (Simple, but does it cover enough?)

  • The Fixed Standard: Setting a specific viewport size (e.g., $1920 \times 1080$) in the Desired Capabilities to ensure consistency across all environments.

  • The Smart Viewport: Using WebUI.setViewPortSize() to explicitly test Mobile, Tablet, and Desktop layouts within a single suite.

The Big Question:

How do you tackle this?

  1. Do you rely on Smart Wait and Self-Healing to find shifted elements?

  2. Do you have a specific Custom Keyword that handles window resizing?

Drop your tips, tricks, or “horror stories” below! Let’s help each other build more robust UI tests. :rocket:

2

Hi there, and thanks for posting in the Katalon community! :hugs:

To help you faster, please review our guide on Custom Keyword here: Introduction to custom keywords in Katalon Studio | Katalon Docs. Double-checking the steps and configurations might resolve the issue.

If the doc doesn’t help, feel free to provide more details, and a community member will assist you soon. Thanks for being a part of our community!

Best,
Elly Tran

3

Maybe @depapp have some ideas :partying_face:

4

Does headless mode has any impact if we select screensize at max ? @qurzunta.kaab

5

Fixed viewport + matrix testing: No “works on my machine”—standardize then emulate devices.

Strategy

WebUI.setViewPortSize(1920, 1080)  // Desktop baseline EVERY test

Matrix: Test Suite Collection > Data-driven rows:

Browser Width Height
Chrome 1920 1080
Chrome 375 667
Firefox 1366 768

Custom Keyword

@Keyword
void testResponsive(int width, int height) {
    WebUI.maximizeWindow()
    WebUI.setViewPortSize(width, height)
    WebUI.delay(2)  // Render
}

CI: Headless Chrome + fixed viewport. Covers 95% devices!

6

maximizeWindow() is unreliable since screen sizes vary and headless Chrome defaults to 800x600 anyway. Use WebUI.setViewPortSize(1024, 768) instead, or pass dimensions from a data file if you need multiple sizes.

Smart Wait and Self-Healing can’t fix elements hidden off-screen. For CI, set the Chrome --window-size argument in Project Settings so the browser matches what your test expects.

7

In my experience, I prefer using
WebUI.setViewPortSize(1920, 1080)
instead of relying on maximizeWindow().

Maximizing the window can behave differently across machines, browsers, OS settings, or CI agents, whereas explicitly setting the viewport gives more predictable and consistent results across environments.

That said, my long‑term conclusion is this:

Most resolution issues are actually locator issues in disguise.

Many overlap or misclick problems usually come from:

  • Using absolute XPaths

  • Clicking parent containers instead of truly interactable child elements

  • Forgetting to ensure scroll visibility before interaction

What helped us far more than just resizing the browser:

  • Prefer attribute‑based, relative locators

  • Always ensure elements are visible and clickable before interacting

  • Perform explicit scrolling only when necessary

In short, window size matters—but robust locators and interaction logic matter much more for building stable, resolution‑independent tests.

8

+1 for using setViewPortSize instead of maximizeWindow, especially in CI.

Also agree that a lot of resolution issues turn out to be locator problems. Fixing visibility and using better selectors usually does more than tweaking screen size.

9

Yes, very true