DEV Community: Gustavo A. Roberto

Building a Chrome Extension That Compares UI Elements Across Pages

Gustavo A. Roberto — Sat, 24 Oct 2026 02:11:57 +0000

Chrome DevTools offers powerful capabilities for inspecting web interfaces.

But when reviewing visual consistency across a product, I often find that the challenge isn't inspecting one element. It's comparing several elements across different screens.

Consider a checkout flow with buttons appearing on different pages. You might want to check whether their typography, padding, colors, and borders are consistent.

Individually inspecting each button and manually comparing its CSS properties becomes repetitive.

I wanted a lightweight tool that could capture those properties, preserve them across navigation, and display the differences in one place.

That idea became Visqora, a free Chrome extension built with React, TypeScript, WXT, and Manifest V3.

What started as a small inspection tool turned into an interesting exercise in browser architecture, asynchronous communication, state management, privacy, and production reliability.

01. Defining the problem

The original goal was straightforward:

Make it easier to compare the computed visual properties of DOM elements, even when those elements belong to different pages.

There was also an important boundary to establish.

Visqora isn't a screenshot regression testing tool.

It doesn't compare images, evaluate visual baselines, or automatically determine whether differences represent defects.

Instead, it compares selected computed CSS properties from DOM elements.

The distinction matters because a different value isn't necessarily an error. Two components may intentionally use different spacing or colors.

Visqora exposes the differences and leaves their interpretation to the developer, QA professional, or designer.

For the initial release, I limited the comparison workspace to five elements.

That constraint kept both the interface and the underlying data model manageable.

02. Architecture across execution contexts

A Chrome extension is not a conventional single-context React application.

Manifest V3 separates functionality across execution environments with different lifecycles and permissions.

Visqora uses three principal contexts:

React Side Panel: The interface where users start inspection, view captured properties, and compare elements.

Background service worker: The orchestration layer responsible for runtime messages, active-tab state, inspection sessions, workspace mutations, and persistence.

Injected inspector: An isolated-world script responsible for interacting with the inspected webpage and capturing computed styles.

These contexts communicate through explicit messages and shared TypeScript contracts.

Architecture overview

flowchart TB
    U["User"]

    subgraph UI["React Side Panel"]
        P["InspectorPanel"]
        C["Pure comparison engine"]
    end

    subgraph BG["MV3 Background Service Worker"]
        W["Message orchestration"]
        L["Inspection lifecycle"]
        WS["Workspace management"]
    end

    subgraph PAGE["Inspected webpage"]
        I["On-demand injected inspector"]
        D["Page DOM and computed styles"]
    end

    S[("chrome.storage.session")]

    U --> P
    P <-->|"Runtime messages"| W
    W --> L
    W --> WS
    W <-->|"Commands and captures"| I
    I <-->|"DOM inspection"| D
    WS <-->|"Persist and restore"| S
    P --> C
    C --> P

Figure 1. Visqora's execution contexts and their main responsibilities.

The diagram illustrates a deliberate separation of concerns.

The Side Panel does not directly inspect the webpage or mutate the authoritative workspace.

The injected inspector doesn't manage the React interface or long-lived comparison data.

The background service worker coordinates the operation and owns workspace mutations.

That separation introduces messaging overhead, but it also gives each component a clearer responsibility.

03. On-demand injection and minimal access

One decision I wanted to preserve was avoiding unnecessary access to webpages.

Visqora doesn't inject a persistent inspector into every page the user visits.

Instead, inspection starts through an explicit user action.

When the user clicks Inspect, the Side Panel requests permission for the current HTTP or HTTPS origin.

The background worker then attempts to communicate with an existing inspector.

If no inspector is available, it uses chrome.scripting.executeScript() to inject the inspector and retries the activation command.

The inspector runs in Chrome's isolated world.

It creates the hover overlay and registers the event listeners needed to identify and capture elements.

When inspection stops, it cleans up the overlay and listeners.

This approach reduces unnecessary interaction with webpages, but it also creates additional lifecycle and orchestration complexity.

The background worker must account for injection failures, navigation, stale requests, and repeated activation.

There is a clear trade-off:

Less persistent page access means more responsibility for correct activation and cleanup.

04. Capturing snapshots instead of DOM elements

Once inspection is active, Visqora uses pointer events to identify the element under the cursor.

The overlay highlights the current target.

When the user selects an element, the inspector creates a serializable snapshot.

The implementation uses getComputedStyle() to read a specific allowlist of 18 CSS properties.

It also captures a generated identifier, the element's tag name, and a bounded structural selector.

A simplified conceptual flow:

DOM element
    ↓
getComputedStyle()
    ↓
Extract 18 supported properties
    ↓
Normalize values
    ↓
Create serializable capture
    ↓
Send capture to background worker
    ↓
Add trusted source metadata
    ↓
Store snapshot in comparison workspace

The important decision is that Visqora stores a snapshot, not a live DOM reference.

A DOM element belongs to a particular document and can disappear after navigation.

A serializable snapshot can remain useful after that document no longer exists.

The background worker adds source metadata such as the originating tab, URL, document identity when available, and capture timestamp.

This also establishes a privacy boundary.

The snapshot extractor does not copy arbitrary HTML, text content, form values, or DOM references into the comparison workspace.

The limitation is equally important: snapshots represent point-in-time values. They don't automatically update when the original element changes.

Figure 2. Single-element inspection showing grouped CSS properties.

05. A pure comparison engine

The comparison engine is deliberately independent of browser APIs.

It receives captured snapshots and produces an ordered set of property comparisons.

For each supported property, it compares the stored values and marks the property as different when values do not match.

Whitespace is normalized, but the engine doesn't attempt deeper semantic equivalence.

For example, it doesn't claim that all differently formatted CSS color values or length units are necessarily equivalent.

This is intentional.

The comparison engine identifies differences in the recorded data. It doesn't attempt to become a full CSS interpretation engine.

The Side Panel chooses its presentation based on the number of snapshots:

With one snapshot, it displays a grouped property inspector.
With two to five snapshots, it displays a comparison table.

Because the engine is pure, the comparison rules can be tested independently of Chrome APIs, DOM access, and React rendering.

That separation made the feature easier to maintain and reason about.

Figure 3. Comparison between two or more elements, highlighting property differences.

06. State management across pages and tabs

Cross-page comparison introduces a lifecycle problem.

The webpage being inspected can navigate, reload, or disappear.

The Side Panel can also close.

And under Manifest V3, the background service worker should not be treated as a permanently running process.

The solution was to distinguish two kinds of state.

Active inspection state

Inspection is tied to the current browser context.

The worker tracks tab, session, operation, and document identity where available.

When navigation or a tab switch invalidates the current inspection, the active interaction is stopped or reset.

Visqora doesn't silently reactivate inspection on the new page.

The user must explicitly start it again.

Comparison workspace

Captured snapshots are different.

They remain useful even when inspection ends.

Visqora preserves them through chrome.storage.session, which allows the workspace to survive navigation and Side Panel reopening within the supported browser session.

The background worker is the single owner of workspace mutations.

To prevent concurrent storage operations from overwriting one another, mutations are serialized through a promise queue.

Stored snapshots are also validated when restored rather than blindly trusted.

This architecture preserves the user's comparison work without treating the current webpage as permanent.

07. Handling stale messages

One subtle challenge in browser extensions is asynchronous timing.

Imagine a user starting inspection and then navigating before the operation finishes.

An injection result, element capture, or state update may arrive after the original document has been replaced.

Without additional checks, the application could associate stale data with the current session.

Visqora addresses this by validating the identities associated with operations and captures.

The background worker checks relevant tab, session, operation, and document information before accepting events.

Document IDs aren't guaranteed to be available for every operation, so the system uses the identities that are available.

This is an important distinction between simply sending messages and designing a reliable message protocol.

A response is not necessarily valid just because it arrived successfully. It must also belong to the operation that is still current.

08. A production failure in the first public release

The first Chrome Web Store release exposed another messaging issue.

After Visqora v0.4.0 was approved, I installed the published extension and opened the Side Panel.

The interface was completely blank.

The console reported an error equivalent to:

Cannot destructure property 'inspection'
as it is undefined.

Initially, this suggested a React initialization issue.

But the problem originated in communication with the background worker.

On startup, the Side Panel requested its initial state using GET_PANEL_STATE.

The published worker used an asynchronous chrome.runtime.onMessage listener that returned a Promise.

In the affected runtime, that approach didn't keep the response channel open as the implementation expected.

The Side Panel received undefined instead of the expected state, and the following React render crashed.

Correcting the runtime response contract

The corrected implementation uses Chrome's callback-based messaging contract.

For asynchronous work, the listener returns true synchronously and later responds through sendResponse.

Conceptually:

chrome.runtime.onMessage.addListener(
  (message, sender, sendResponse) => {
    if (message.type !== 'GET_PANEL_STATE') {
      return false;
    }

    getPanelState()
      .then(sendResponse)
      .catch((error) => {
        sendResponse({
          error: String(error)
        });
      });

    return true;
  }
);

Illustrative code showing the asynchronous response-channel contract, not a direct extract from the repository.

The hotfix also strengthened response validation in the Side Panel.

Instead of assuming every message contains a valid state object, the interface now checks incoming responses and renders an explicit error when they are invalid.

Workspace restoration also handles empty, malformed, or unavailable session storage.

These improvements address the original failure while making unexpected communication problems easier to diagnose.

09. The real surprise: artifact drift

The investigation uncovered an additional problem.

The published v0.4.0 Side Panel bundle was byte-for-byte identical to the corresponding local bundle.

The background worker was not.

The callback-style response correction had already entered the repository after the Store artifact was created, inside an unrelated change.

As a result, the current local code behaved correctly while the published package still contained the faulty implementation.

The problem wasn't minification or an unexpected React production optimization.

We had been testing code that was different from the code users actually installed.

That changed the focus of the release process.

Instead of validating only the repository's current state, we needed to validate the exact production artifact being distributed.

10. Testing and releasing v0.4.1

The v0.4.1 hotfix concentrated on reliability.

We added regression coverage for:

Initial Side Panel rendering.
Missing and malformed worker responses.
Runtime response-channel behavior.
Empty and restored comparison workspaces.
Session-storage failures.
Asynchronous response success and failure.

The release passed 60 automated tests across eight files, along with linting, formatting, type checking, and production build verification.

We also tested the generated production extension in Chrome.

The final interactive checks were particularly important because headless testing couldn't fully reproduce every user permission interaction.

After testing, the corrected v0.4.1 package was submitted to the Chrome Web Store.

The published update was installed and verified successfully.

The lesson was broader than fixing a message listener.

The actual installation artifact is part of the software we need to test.

11. What I learned

A small browser extension can involve surprisingly rich architectural decisions.

Building Visqora reinforced several principles I value in frontend engineering.

Treat execution contexts as explicit boundaries

The React UI, service worker, and injected page code have different responsibilities and lifecycles.

Communication between them needs contracts, validation, and failure handling.

Keep a single owner for mutable state

Centralizing workspace mutations in the background worker simplifies consistency, even though it means state changes must cross a messaging boundary.

Separate live interactions from historical data

Inspection belongs to a specific document and session.

Captured snapshots can remain useful after that context disappears.

Keeping the two separate enables cross-page comparisons without pretending DOM elements live forever.

Design for privacy through data minimization

An inspector doesn't need to capture everything it can access.

Extracting a bounded set of properties reduces unnecessary data collection and clarifies the feature's purpose.

Test failures at integration boundaries

A successful unit test can't prove that Chrome messaging, extension permissions, and packaged assets behave correctly together.

The release artifact and the browser runtime must also be part of verification.

Keep product scope focused

Visqora isn't trying to replace DevTools, screenshot regression platforms, or design-system auditing tools.

It focuses on one problem: helping people inspect and compare implementation details efficiently.

12. What's next?

Visqora is still an early-stage tool.

For now, I'm focused on understanding how frontend developers, QA engineers, and designers use it in real workflows.

The extension is free and doesn't require an account.

Future improvements will depend on real feedback rather than adding features simply to expand the product.

Building Visqora has been a useful exercise in browser APIs, TypeScript contracts, state ownership, DOM inspection, asynchronous communication, and software distribution.

And if there's one lesson I'll carry into future releases, it's this:

The product is not the source code sitting in the repository. It's the software that users actually run.

Explore Visqora

Chrome Web Store: https://chromewebstore.google.com/detail/visqora/djjlhjglgjjaeafhekmejaeobfmhpngh

Product website: https://visqora.55onze.com

55onze: https://55onze.com

Gustavo A Roberto · Frontend Engineering, Architecture & Technical Leadership

From Server-Rendered Forms to a Framework-Agnostic JavaScript Library

Gustavo A. Roberto — Thu, 22 Oct 2026 22:19:52 +0000

A few years ago, while working on a Java and Thymeleaf application, I faced an interesting frontend challenge.

One of its workflows involved collecting notary-related information through a form that spanned multiple pages, with different validation requirements along the way.

The challenge wasn't creating inputs or rendering HTML. It was coordinating the entire experience while preserving user progress between separate documents.

That problem eventually inspired Demetria, a JavaScript library I recently revisited and rebuilt as an open-source project.

In this article, I want to share the problem that inspired it, the architecture behind the current implementation, and some of the trade-offs involved in building a framework-agnostic library.

01. The problem with multi-page forms

When working with modern frontend frameworks, it's easy to take client-side state management for granted.

But in a traditional server-rendered application, navigating between pages can mean loading an entirely new HTML document.

Any state stored exclusively in JavaScript memory disappears.

For a complex form, this creates several challenges:

Preserving previously entered values.
Tracking progress through multiple steps.
Enforcing validation before moving forward.
Keeping form behavior consistent between pages.
Avoiding duplication of navigation and state-management logic.

In the original application, I used localStorage to maintain form state between pages.

That solved the immediate problem, but it also raised a broader architectural question:

Could we describe an entire multi-step form as data and let a reusable library handle its rendering, state, validation, and navigation?

That was the idea behind Demetria.

The name itself came from Demeter, the Greek goddess associated with agriculture and seasonal cycles. I liked the analogy between the progression of seasons and the different stages of a form.

02. Rebuilding an old idea

Years later, I returned to Demetria with more experience in frontend architecture and library design.

I didn't want to build another comprehensive form management framework.

Libraries such as React Hook Form already solve many problems extremely well, but my goal was different.

I wanted something that could work in a modern application or a traditional server-rendered system without requiring either one to adopt a particular frontend framework.

The initial requirements were:

Use plain JavaScript or TypeScript.
Accept JSON-compatible form definitions.
Generate native HTML elements.
Support multiple steps and built-in validation.
Allow optional persistence across HTML documents.
Leave visual styling to the consuming application.
Keep runtime dependencies at zero.
Treat accessibility as a core design concern.

These requirements shaped the boundaries of the library.

Rather than building a large ecosystem, I wanted a small tool with a clearly defined responsibility.

03. Architecture: separating responsibilities

One of the most important decisions was keeping form orchestration separate from presentation.

The current architecture can be understood through three main responsibilities: the form engine, the DOM renderer, and optional persistence.

Architecture diagram

flowchart TB
    A["Host application"]
    B["JSON-compatible schema"]
    C["createForm(options)"]
    D["Form engine"]
    E["Native DOM renderer"]
    F["HTML form"]
    G["User interaction"]
    H["Optional Web Storage"]
    I["Host CSS and integration"]

    A --> C
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> D
    D <--> H
    A --> I
    I --> F

Figure 1. A conceptual overview of Demetria's architecture and integration boundaries.

The form engine

The engine coordinates form state, validation, and navigation.

It understands the schema, current step, values, and transition rules without depending on the application's visual presentation.

This separation allows the same form behavior to be used in different integration environments.

The DOM renderer

The renderer transforms the schema into native HTML elements, including form, fieldset, legend, label, input, select, textarea, and button.

It also connects user interactions to the form engine.

Using native browser elements reduces the need for custom behavior and makes it easier to preserve familiar keyboard interactions and semantics.

Demetria deliberately ships without mandatory CSS.

Applications can use the generated styling hooks to apply their own visual identity.

Optional persistence

The third responsibility is state persistence.

By default, Demetria keeps its state in memory.

When an application needs to preserve data between page loads, it can explicitly enable sessionStorage or localStorage.

This is particularly important for the problem that originally inspired the project.

The library doesn't need to become a router or manage the server-side application lifecycle. It only needs to restore compatible form state when the application initializes it again.

That boundary keeps the implementation focused.

04. A declarative API

The public API revolves around createForm().

Instead of manually creating fields and coordinating individual inputs, the consuming application provides a JSON-compatible schema describing the form.

Here is a working example based on Demetria's v0.1.1 API.

First, create a target element:

<div id="demetria-form"></div>
<script type="module" src="./app.js"></script>

Then define the form in JavaScript:

import { createForm } from 'demetria';

const schema = {
  id: 'registration',
  steps: [
    {
      id: 'personal',
      title: 'Personal information',
      fields: [
        {
          name: 'fullName',
          type: 'text',
          label: 'Full name',
          required: true
        },
        {
          name: 'email',
          type: 'email',
          label: 'Email'
        }
      ]
    },
    {
      id: 'preferences',
      title: 'Preferences',
      fields: [
        {
          name: 'newsletter',
          type: 'checkbox',
          label: 'Receive updates'
        },
        {
          name: 'contactMethod',
          type: 'select',
          label: 'Preferred contact method',
          required: true,
          options: [
            { label: 'Email', value: 'email' },
            { label: 'Phone', value: 'phone' }
          ]
        }
      ]
    }
  ]
};

const form = createForm({
  schema,
  target: '#demetria-form',
  onComplete(values) {
    console.log('Completed form:', values);
  }
});

form.mount();

Demetria generates the form, handles transitions between steps, validates fields, and passes the completed values to the application.

Notice that email doesn't include required: true.

In Demetria, fields are optional by default. An optional email can be left empty, but a non-empty value must satisfy the applicable email validation.

This distinction is important because optional does not mean unvalidated.

Why a JSON-compatible schema?

Choosing a declarative schema creates a clear contract between configuration and behavior.

It allows a form definition to be serialized, shared, and understood without executing arbitrary JavaScript from the schema.

But that choice has trade-offs.

A declarative format can be less expressive than an API built around callbacks and custom components.

For the initial release, I preferred a smaller, predictable contract over supporting every possible form requirement.

The objective was to make the common behavior reliable before introducing greater extensibility.

05. One library, two navigation models

A particularly important architectural requirement was supporting both single-page and multi-page flows.

Single-page forms

In a single-page flow, all steps exist within the same document.

Demetria updates the active step without requiring a full browser navigation.

The engine preserves values as users move forward and backward.

Multi-page forms

In a multi-page flow, the browser loads separate HTML documents.

The host application controls navigation, while Demetria restores compatible form state through explicitly configured persistence.

For example:

const form = createForm({
  target: '#demetria-form',
  schema,
  persistence: {
    type: 'sessionStorage',
    key: 'registration-flow'
  },
  stepId: 'preferences'
});

form.mount();

The stepId option selects the step that the current document should render.

Different pages can initialize Demetria with the same schema and persistence key while explicitly selecting their corresponding step.

This approach avoids introducing a client-side router.

It also makes the library useful in traditional applications where navigation is controlled by the server or the surrounding application.

The persistence trade-off

Browser storage is convenient, but it comes with limitations.

Both localStorage and sessionStorage are accessible to JavaScript executing in the same origin.

They should not automatically be treated as safe places for sensitive personal information.

For that reason, Demetria doesn't persist form state by default.

Applications must explicitly enable it and remain responsible for evaluating the security and privacy requirements of their data.

In applications collecting sensitive information, server-side persistence with appropriate security controls may be more suitable.

06. Accessibility is more than semantic HTML

Accessibility was one of the areas I wanted to approach differently when rebuilding Demetria.

A form-generation library has an important responsibility: the markup and behavior it produces become part of the user experience in every consuming application.

That means accessibility problems can propagate across integrations.

The renderer therefore emphasizes:

Native semantic controls.
Programmatically associated labels.
Visible required-field indicators.
Validation errors associated with their fields.
Keyboard-operable navigation.
Focus management after validation failures.
Predictable focus when changing steps.

But semantic HTML alone isn't enough.

Focus and state transitions are particularly important in multi-step experiences.

A real issue discovered during testing

During the accessibility audit for v0.1.1, we found that completing a form could cause keyboard focus to be lost.

The renderer unnecessarily rebuilt the form after completion.

That removed the focused button from the document, leaving focus on the page body.

Instead of adding a workaround that manually restored focus, we removed the unnecessary renderer rebuild.

This preserved the focused element and corrected the underlying lifecycle behavior.

It was a useful reminder that accessibility issues can reveal deeper implementation problems.

The same audit identified improvements related to accessible naming, responsive reflow, contrast, and ARIA announcements.

Automated browser tests and axe-core checks helped verify the fixes, but I don't consider those results proof of complete WCAG 2.2 AA conformance.

Manual assistive-technology testing remains important.

07. Zero runtime dependencies as a design constraint

Another deliberate choice was keeping Demetria free of runtime dependencies.

The browser already provides most of the capabilities required for this problem:

Native DOM APIs.
HTML form controls.
Events.
Web Storage.
JavaScript data structures.

Adding a large runtime dependency tree would introduce additional compatibility considerations and maintenance costs.

That doesn't make dependencies inherently undesirable.

It simply means they should solve a problem that justifies their cost.

Demetria still uses development tools for TypeScript compilation, testing, linting, and accessibility verification.

The goal is to keep the library lightweight for the applications that consume it.

08. Testing the actual distribution

One lesson I wanted to apply during the rebuild was that successfully compiling source code isn't enough to prove that a library can be consumed.

The initial historical npm release had packaging problems.

For the new implementation, I wanted to verify the actual package artifact, not only the TypeScript sources.

That meant checking the compiled JavaScript, type declarations, package exports, and tarball contents.

We also added unit tests and browser-based checks for the generated forms and documentation examples.

The first functional release, v0.1.0, established the library's core behavior.

The next patch, v0.1.1, focused on accessibility and stability improvements without introducing breaking API changes.

I prefer that sequence to rushing into new features before the existing functionality is reliable.

09. What I learned

Rebuilding Demetria reinforced a few engineering principles that have become important in my work.

A good abstraction knows what it doesn't own

Demetria handles form orchestration, but it doesn't need to become a frontend framework, router, validation ecosystem, or form-building platform.

Keeping those responsibilities separate makes the library easier to reason about.

Framework independence should solve a real problem

Being framework-agnostic isn't automatically valuable.

In this case, it supports a concrete integration requirement: generating form experiences in applications that may not use a modern frontend framework.

Accessibility is part of behavior

Labels and semantic elements matter, but accessibility also depends on navigation, focus, validation, announcements, and lifecycle behavior.

It needs to influence architecture and testing, not just markup.

Declarative APIs create valuable boundaries

A JSON-compatible schema makes the form structure explicit.

That improves portability and predictability while establishing clear limitations around extensibility.

Small, functional releases build confidence

A library doesn't need dozens of features to be useful.

A focused implementation, working examples, accurate documentation, and a reliable distribution process are a much better starting point.

10. What's next?

Demetria is still an early-stage open-source project.

Future improvements may include conditional fields, custom validation rules, and more flexible renderer customization.

But I don't want to expand the API simply to increase the number of features.

The next changes should come from actual integration needs and feedback from developers using the library.

For now, the main goal is to make the existing functionality understandable, accessible, and reliable.

Demetria started with a complex form in a server-rendered Java application.

Years later, the same idea became an opportunity to revisit library architecture, declarative APIs, browser persistence, and accessibility.

And that's probably my favorite part of the project.

Sometimes, revisiting an old engineering problem with a different perspective is enough to turn a specific solution into something reusable.

Explore Demetria

GitHub: https://github.com/gustavoaroberto/demetria
Documentation and live examples: https://gustavoaroberto.github.io/demetria/
npm: https://www.npmjs.com/package/demetria

Gustavo A Roberto · Frontend Engineering, Architecture & Technical Leadership