Building Papio Selector: A Chrome Extension for QA Engineers

How It Started

It was a Sunday afternoon. I was writing Playwright tests for a particularly gnarly Shadow DOM component and spending more time inspecting the DevTools panel than writing actual test logic.

The thought: what if the DevTools panel could just generate the right locator for me, already validated against the framework I'm using?

Four hours later I had a prototype. Six months later, Papio Selector is a production Chrome extension with thousands of active users in the QA community.

The Core Problem

Every test automation engineer knows the workflow:

Open DevTools
Inspect element
Try to figure out the best locator (id? data-testid? CSS? XPath?)
Copy it to your test
Run the test → locator is wrong or fragile
Repeat

This loop can eat an hour for complex components. For Shadow DOM, it can eat a day.

What Papio Selector Does Differently

Multi-Framework Locator Generation

Instead of giving you one locator, Papio generates the optimal locator for each framework simultaneously:

Playwright:  page.getByRole('button', { name: 'Add to Cart' })
Selenium:    driver.find_element(By.CSS_SELECTOR, '[data-testid="add-to-cart"]')
Cypress:     cy.get('[data-testid="add-to-cart"]')
WebdriverIO: $('[data-testid="add-to-cart"]')

It also scores each locator for stability — warning you when you're about to use something fragile.

Shadow DOM Intelligence

Regular DevTools selector copy breaks completely with Shadow DOM. Papio traverses the shadow tree and generates the correct pierce selector or host-based selector depending on your framework.

// Generated for Playwright Shadow DOM
await page.locator('product-card >> shadow >> button[data-action="add"]').click();

Live Validation

Before you copy a locator, Papio tests it right there in the extension — showing you how many elements it matches, whether it's unique, and how it performs across viewport sizes.

The Engineering Challenges

Challenge 1: Content Script Architecture

Chrome extensions that interact with page DOM run in content scripts, which have a constrained execution environment. Making bidirectional communication work between the DevTools panel (which runs in the extension context) and the content script (which runs in the page context) required a careful message-passing architecture.

Challenge 2: Shadow DOM Traversal

The Chrome DevTools API doesn't expose a clean way to traverse shadow roots programmatically. I ended up implementing a recursive shadow tree walker that handles both open and closed shadow roots (the latter with some creative work-arounds).

Challenge 3: Framework Detection

Papio auto-detects which framework your test suite uses by inspecting the page's loaded scripts, package.json hints from DevTools, and URL patterns. Getting this heuristic right took more iteration than any other feature.

What's Next: Papio Playwright Studio

The next evolution is Papio Playwright Studio — a full no-code test recording and editing environment built directly into DevTools. Record interactions, generate complete test files, mock network requests, and run tests in-browser without leaving DevTools.

The alpha is in active development. If you're a QA engineer who'd like early access, join the AIQEAcademy waitlist.

Lessons for Extension Developers

If you're building a QA-focused Chrome extension:

Invest in the DevTools panel UI first — that's where your power users live
Make copy-to-clipboard one click — friction kills adoption
Support all major frameworks from day one — the QA community is fragmented
Get into the Chrome Web Store early — the review process takes longer than you think

The full source architecture is documented in the AIQEAcademy course on Browser Automation & Extension Testing, launching Q2 2025.