set device does not apply deviceScaleFactor - HiDPI screenshots not possible

[Shpigford]

Summary

The set device command accepts Playwright device names (e.g., "Desktop Chrome HiDPI") but does not apply the deviceScaleFactor property from those device presets. This makes it impossible to capture true HiDPI/retina screenshots, which are essential for marketing materials.

Steps to Reproduce

# Start fresh session and set HiDPI device
agent-browser --session test-hidpi set device "Desktop Chrome HiDPI"

# Open any page
agent-browser --session test-hidpi open "https://example.com"

# Check the devicePixelRatio
agent-browser --session test-hidpi eval "window.devicePixelRatio"
# Returns: 1 (should be 2)

# Take screenshot
agent-browser --session test-hidpi screenshot ./test.png

# Check dimensions
sips -g pixelWidth -g pixelHeight ./test.png
# Returns: 1280x720 (should be 2560x1440 for 2x scale)

Expected Behavior

The "Desktop Chrome HiDPI" device in Playwright has these properties:

const { devices } = require('playwright');
console.log(devices['Desktop Chrome HiDPI']);
// {
//   "userAgent": "Mozilla/5.0 ...",
//   "viewport": { "width": 1280, "height": 720 },
//   "screen": { "width": 1792, "height": 1120 },
//   "deviceScaleFactor": 2,  // <-- This should be applied
//   "isMobile": false,
//   "hasTouch": false,
//   "defaultBrowserType": "chromium"
// }

When using set device "Desktop Chrome HiDPI":

• window.devicePixelRatio should return 2
• Screenshots should be 2560x1440 pixels (viewport × deviceScaleFactor)
• UI elements should render at the same logical size but with 2x pixel density

Actual Behavior

• window.devicePixelRatio returns 1
• Screenshots are 1280x720 pixels (1x, not 2x)
• The deviceScaleFactor from the device preset is ignored

It appears that set device only applies:

• ✅ viewport (width/height)
• ✅ userAgent (presumably)
• ❌ deviceScaleFactor (not applied)
• ❓ screen (unknown)
• ❓ hasTouch (unknown)

Why This Matters

HiDPI screenshots are essential for:

• Marketing materials - Product Hunt, landing pages, social media
• Documentation - Retina-quality docs and tutorials
• App Store assets - iOS/Mac App Store require high-res screenshots
• Design handoffs - Crisp screenshots for design review

Without deviceScaleFactor support, users must bypass agent-browser entirely and use Playwright directly to capture marketing-quality screenshots.

Workaround

Use Playwright directly with deviceScaleFactor in the browser context:

import { chromium } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({
  viewport: { width: 1440, height: 900 },
  deviceScaleFactor: 2,  // This works in Playwright directly
});

const page = await context.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'screenshot.png' });
// Result: 2880x1800 pixels (true 2x retina)

Suggested Fix

When applying device settings in the browser context, include deviceScaleFactor:

// Pseudocode for what the fix might look like
const device = playwright.devices[deviceName];
const context = await browser.newContext({
  viewport: device.viewport,
  userAgent: device.userAgent,
  deviceScaleFactor: device.deviceScaleFactor,  // Add this
  screen: device.screen,
  hasTouch: device.hasTouch,
  isMobile: device.isMobile,
});

Feature Request: Direct deviceScaleFactor Setting

Additionally, it would be useful to set deviceScaleFactor directly without needing a device preset:

# Proposed new command
agent-browser set scale 2

# Or
agent-browser set deviceScaleFactor 2

This would allow users to combine custom viewports with custom scale factors:

agent-browser set viewport 1440 900
agent-browser set scale 2
agent-browser screenshot ./retina-screenshot.png
# Result: 2880x1800 pixels

Environment

• agent-browser version: v1.1.1
• Node.js version: v24.6.0
• OS: macOS (Darwin 25.2.0)
• Playwright version: (bundled with agent-browser)

Related

• Playwright docs on deviceScaleFactor: https://playwright.dev/docs/emulation#devices
• Playwright devices list includes HiDPI presets: Desktop Chrome HiDPI, Desktop Edge HiDPI, Desktop Firefox HiDPI

[borekb]

I tested this with agent-browser 0.9.1 which includes the fix from #270. The good news is that window.devicePixelRatio is now correctly set:

$ agent-browser set device "Desktop Chrome HiDPI"
$ agent-browser eval "window.devicePixelRatio"
2

However, the actual screenshot dimensions remain unchanged:

Mode	devicePixelRatio	Screenshot dimensions
Desktop Chrome HiDPI	2	1280×720
Desktop Chrome	1	1280×720

So the page thinks it's running on a retina display (CSS media queries, srcset, etc. will work correctly), but screenshots are still captured at 1x logical pixel dimensions, not 2x physical pixels.

This matches the note in the PR #270 code: since deviceScaleFactor is set via CDP (Emulation.setDeviceMetricsOverride) on an already-existing browser context, Playwright captures screenshots at viewport size rather than viewport × scale. For true HiDPI screenshots (e.g., 2560×1440 for a 1280×720 viewport at 2x), the scale factor would need to be set at context creation time.

Tested on macOS (Darwin 25.2.0), agent-browser 0.9.1.

[borekb]

There's also a CSS zoom workaround worth mentioning: set the viewport to 2× the desired size and apply zoom: 2 on the <html> element, so the page lays out as if the viewport were half the size but the screenshot captures all the physical pixels.

$ agent-browser set viewport 2560 1440
$ agent-browser eval "document.documentElement.style.zoom = '2'"
$ agent-browser screenshot retina.png
# Result: 2560×1440 screenshot with content laid out as if 1280×720

This mostly works — text is sharp, images render at higher resolution, and standard CSS units (px, rem, %, flexbox/grid) all behave correctly. However, vh and vw units break: they still refer to the actual viewport (2560×1440), not the zoomed layout viewport (1280×720). In practice, this means elements using Tailwind's min-h-screen (which compiles to 100vh) end up being twice as tall as the visible area, so centered hero sections and full-height layouts get misaligned.

For pages that don't rely on viewport units, the zoom trick is a reasonable workaround. For pages that do (which is most modern landing pages), it's not usable.