Browser Configuration

Configure per-test browser settings including engine selection, viewport size, timeouts, headless mode, Real Browser mode for bot detection bypass, and granular browser permissions.

Overview

Every test in QA Studio can have its own browser configuration. These settings control which browser engine is used, the viewport dimensions, step timeouts, and advanced options like bot detection bypass and permission grants. Browser settings are configured in the test's settings panel within the test builder.

Browser Selection

QA Studio supports three browser engines through Playwright. Each test can target a different browser.

Browser	Engine	Notes
Chromium	Blink (Chrome/Edge)	Default browser. Fastest execution. Most widely used rendering engine. Best compatibility with web standards.
Firefox	Gecko	Mozilla's rendering engine. Useful for testing Firefox-specific behavior and ensuring cross-browser compatibility.
WebKit	WebKit (Safari)	Apple's rendering engine used in Safari. Test Safari compatibility without needing a Mac or iOS device.

Viewport Configuration

The viewport setting controls the browser window dimensions for the test. It is specified as width x height in pixels.

Setting	Default	Description
Width	1280	Browser viewport width in pixels
Height	720	Browser viewport height in pixels

Common viewport presets:

• Desktop: 1280x720, 1920x1080
• Tablet: 768x1024 (iPad), 1024x768 (landscape)
• Mobile: 375x667 (iPhone SE), 390x844 (iPhone 14), 360x800 (Android)

Viewport size affects responsive layouts, media queries, and element visibility. If your application has responsive breakpoints, create separate tests with appropriate viewport sizes to verify each layout.

Timeout

The timeout setting controls the maximum wait time per step in milliseconds. If a step (such as waiting for a selector, navigation, or assertion) does not complete within this time, it fails with a timeout error.

Setting	Range	Default
Timeout	1,000 ms – 120,000 ms	30,000 ms (30 seconds)

Adjust the timeout based on your application's performance:

• Decrease for fast applications to catch slow-loading issues earlier
• Increase for applications with heavy API calls, server-side rendering, or slow third-party dependencies

Headless Mode

By default, tests run in headless mode, which means the browser runs without a visible window. This is faster and uses less resources, making it ideal for automated and CI/CD environments.

Setting	Default	Description
Headless	true	When enabled, the browser runs without a visible window. Disable to see the browser during execution.

Disable headless mode when you want to visually observe test execution for debugging. The browser window will appear on screen and you can watch each step execute in real time. This is useful for understanding failures or verifying that selectors target the correct elements.

Real Browser Mode

Real Browser mode is an advanced feature that uses your system's installed Google Chrome instead of Playwright's bundled Chromium. This is essential for testing websites that employ bot detection systems.

What It Does

When Real Browser mode is enabled, QA Studio:

• Launches your system's Google Chrome installation instead of Playwright's Chromium
• Patches navigator.webdriver to return false (Playwright normally sets this to true)
• Disables all automation flags and indicators that bot detection scripts look for
• Uses a realistic user agent string from a real Chrome installation
• Runs in headed mode (visible browser window) for maximum authenticity

Detection Comparison

The following table shows how standard Playwright and Real Browser mode compare against common bot detection signals:

Detection Signal	Standard Playwright	Real Browser Mode
navigator.webdriver	true (detected)	false (passes)
Automation flags	Present (detected)	Removed (passes)
User agent string	Contains "HeadlessChrome"	Real Chrome user agent
Chrome runtime	Missing window.chrome	Full window.chrome object
WebGL renderer	Software renderer	Hardware GPU renderer
Browser plugins	Empty array	Real plugin list

Requirements

• Google Chrome must be installed on the server/machine running QA Studio
• The Chrome installation must be accessible at the standard system path
• Real Browser mode always runs in headed mode (a visible browser window is required)

When to Use Real Browser Mode

Enable Real Browser mode when testing sites protected by:

• Cloudflare Bot Management / Turnstile challenges
• Akamai Bot Manager
• PerimeterX / HUMAN bot detection
• DataDome bot protection
• Any site that blocks requests from automated browsers

Browser Permissions

QA Studio allows you to grant browser permissions for each test. Permissions are passed directly to the Playwright browser context, simulating user-granted permission prompts.

Available Permissions

Permission	Description
geolocation	Allows the page to access the user's geographic location via navigator.geolocation
camera	Grants access to the device camera via getUserMedia
microphone	Grants access to the device microphone via getUserMedia
clipboard-read	Allows reading from the system clipboard via navigator.clipboard.readText()
clipboard-write	Allows writing to the system clipboard via navigator.clipboard.writeText()
notifications	Allows the page to show desktop notifications via the Notifications API

How to Grant Permissions

In the test's browser configuration panel, toggle the permissions you want to grant. When the test runs, these permissions are set on the Playwright browser context before any page navigation, so the page sees them as already granted — no permission dialogs will appear.

Mock Geolocation

QA Studio can mock the browser's geolocation API to return specific coordinates. This is useful for testing location-dependent features like store finders, delivery area checks, or location-based content.

Setting Up Mock Geolocation

In the test's browser configuration, provide:

Field	Description	Example
Latitude	Geographic latitude in decimal degrees	37.7749 (San Francisco)
Longitude	Geographic longitude in decimal degrees	-122.4194 (San Francisco)

When mock geolocation is configured, any call to navigator.geolocation.getCurrentPosition() or navigator.geolocation.watchPosition() on the page will return the specified coordinates instead of the real device location.

Example: Testing a Store Locator

To test a store locator that shows nearby stores based on the user's location:

1. Enable the geolocation permission in browser permissions
2. Set latitude to 40.7128 and longitude to -74.0060 (New York City)
3. Add a Navigate step to the store locator page
4. Click the "Find Nearby Stores" button
5. Assert that New York area stores are displayed

Run the same test with different coordinates (e.g., 51.5074, -0.1278 for London) to verify that location-specific results change appropriately.

Configuration Summary

Here is a complete summary of all browser configuration options:

Setting	Default	Options / Range
Browser	Chromium	Chromium, Firefox, WebKit
Viewport Width	1280	Any positive integer (pixels)
Viewport Height	720	Any positive integer (pixels)
Timeout	30000 ms	1000 – 120000 ms
Headless	true	true / false
Real Browser	false	true / false
Permissions	None	geolocation, camera, microphone, clipboard-read, clipboard-write, notifications
Geolocation Latitude	None	-90 to 90 (decimal degrees)
Geolocation Longitude	None	-180 to 180 (decimal degrees)

Best Practices

• Start with defaults — Chromium, 1280x720, 30s timeout, headless mode. Only change settings when you have a specific reason.
• Test multiple browsers — clone critical tests and set them to run on Firefox and WebKit to catch cross-browser issues.
• Use responsive viewports — if your app has responsive breakpoints, create test variants with mobile and tablet viewports.
• Reserve Real Browser mode — only enable it for sites with active bot detection. It is slower and requires Chrome to be installed.
• Keep timeouts reasonable — a 30-second timeout is generous for most applications. Lower it to 10-15 seconds for fast apps to catch performance regressions. Raise it only for known slow operations.
• Consistent viewports for visual regression — when using visual regression testing, ensure viewport settings are identical across runs to avoid false diffs from layout differences.