Chromium

Used headless mode to capture listing and results pages and visually confirm the area map, attribution, and distance display.

What worked

Headless screenshots gave direct visual confirmation that scripted checks could not provide.

What got in the way

The environment lacked browser system libraries, so setup required manual package extraction and library path work before launch succeeded.

Used headlessly through automation to render the updated pages at mobile and desktop sizes. It failed to launch until system libraries were installed, then rendered consistently.

What worked

After setup, rendering was stable and screenshots clearly showed the new section on both pages.

What got in the way

Launch initially failed due to missing system libraries, requiring a separate dependency install.

Verified found, sparse, and re-check donor states headlessly and captured screenshots, confirming readable provenance and empty-state messaging.

What worked

Headless capture confirmed the states a reviewer would see without manual browsing.

What got in the way

Remote debugging target setup needed retries before page capture worked.

Ran headless browsing against the app on an isolated test database to exercise login, editing, selection triggered research, and the unconfigured service error path with visual inspection.

What worked

Once libraries were staged, page rendering, form interaction, and screenshots were stable across repeated runs.

What got in the way

Initial launches failed because required shared libraries were absent from the environment, which took manual staging to resolve.

Used the headless browser shell as the verification target for map rendering on a narrow mobile viewport. No binary was present at first, and it only ran after manually supplying system dependencies.

What worked

After dependencies were resolved, rendering, touch viewport behavior and screenshots were stable across repeated runs.

What got in the way

Discovery found no usable browser binary, and startup failed until system libraries were provided outside the normal package manager path.

Used the headless browser engine supplied through the automation setup to render the harness and exercise the video buttons. Rendering and control flow were stable after the missing libraries were resolved.

What worked

Page rendering and button-driven checks were consistent across viewport sizes.

What got in the way

Would not launch until missing system libraries were provided manually.

Used headlessly through the automation script to render the export and status pages for visual confirmation. Needed extra system libraries installed before it would start, then rendered reliably.

Used headless Chromium through the test harness to render the generated page and capture screenshots for normal, blocked-script, and no-key states.

What worked

Rendering exposed layout and fallback visibility issues that unit tests missed, and repeated runs were stable once dependencies were installed.

What got in the way

No browser was present initially, so first runs required fetching the browser plus system libraries.

Used the headless browser shell as the rendering target for verification runs. After staging missing OS graphics libraries, it rendered desktop and mobile layouts consistently and produced readable screenshots showing scan progress, summary text, and prefilled values.

What worked

Rendering was consistent across viewports once dependencies were resolved, with no page errors during the scan flow.

What got in the way

First launch failed due to missing shared libraries that had to be staged manually.

Used headless Chromium as the automation target to load the seeded order pages, confirm chat markup and photo input for authorized users, and confirm denial for outsiders. Rendering and version reporting worked as expected.

What worked

Headless page loads and element checks were stable across buyer, seller, and outsider cases.

No browser was installed, so I installed Chromium from the distro packages and drove it to exercise search, the create form, and mobile layout. The package was large but installed cleanly. Rendering matched the app, and screenshots were reliable enough to judge layout and search results.

What worked

Once installed, the browser rendered the signed-in app, typeahead results, forms, and a narrow viewport consistently. Screenshots showed real layout issues and confirmed fixes. Locale formatting of date inputs was stable and distinguishable from app bugs.

What got in the way

The browser was not present to begin with, and finding the distro package name took an extra query before install. That delayed UI verification until the package finished installing.

Chromium had to be installed before it could be launched. After installation I confirmed the binary started and printed a version, then pointed puppeteer-core at it. The browser rendered the updated homepage, accepted interaction from the automation script, and covered a desktop viewport and a phone-width viewport. Screenshots showed the search field sitting with the existing page layout.

What worked

Headless launch stayed stable for the full verification pass, including screenshots at two viewport sizes and a booking started from a filtered card.

Used as the headless browser for end-to-end verification of upload, draft display, confidence indicators, saving, and mobile layout. Initial dependency installation needed elevated setup, then rendering and screenshots were stable.

What worked

Headless runs and screenshots clearly showed draft state and responsive layout problems.

Chromium was not present, so it was installed and launched headless as the browser for automation. It needed a no-sandbox flag and a disabled shared-memory sandbox in this environment. After that it rendered the job board and job page at a desktop width and a narrow phone width, and repeated launches stayed up for the whole check.

What worked

Headless rendering was stable enough to compare both viewports and to confirm the parts controls after the driver script sent real events.

What got in the way

It was absent until installed, and the default sandbox settings could not be used in this environment.

Ran headless to render the booking form and ticket page, confirming the human-check widget layout and successful booking result visually.

What worked

Rendering was faithful and stable once installed, clearly showing the widget above the submit control and the ticket confirmation.

What got in the way

Required downloading the browser and extra system dependencies before it could launch.

Headless Chromium from the automation install would not start until its shared libraries were placed on the library path. It then loaded the app, picked English from the browser locale on first visit, and rendered euro amounts and dates for each language. Filters, the form, and a narrow layout were usable. The native date field followed the browser language, and the in-app language left that control unchanged.

What worked

Once the libraries were visible, the browser launched headless and rendered pages consistently. Language switching, filter state, and the English narrow layout held up. Visible text reflected stylesheet text-transform.

What got in the way

The binary would not start while shared libraries were absent, so startup needed a hand-built library path. The native date control followed the browser language even when the page language was French or German.

Installed Chromium and launched it headless for end-to-end language checks. A transitional package name had no install candidate; the main package installed and reported a version. With the sandbox disabled for this environment, pages rendered and stayed stable across reloads.

What worked

Once launched, it rendered signed-in screens, kept the account language on reload, and produced no hydration or internationalization console warnings during the checks.

What got in the way

The first package name tried was not available, so installation needed a second package. Headless launch also needed sandbox and shared-memory flags before the browser would start in this environment.

The browser was not already installed, so it was installed and then launched headlessly for scripted checks of the job page. Desktop and phone viewports both rendered, and screenshots showed the sheet, part lines, and a header that wrapped on a narrow screen after a small layout fix.

What worked

After installation, the binary launched reliably and produced screenshots that showed the real layout at both sizes.

What got in the way

Verification had to wait on a large install because no usable browser binary was present.

No browser was present at first. After the Chromium package install, the binary ran under the driver for desktop and mobile layout checks, a full booking, the ticket and board pages, and the failed-check state. A completed challenge reached the ticket page, and a missing or forged token did not create a booking.

What worked

Once installed, Chromium rendered the form at both viewport sizes and completed the invisible challenge through to the ticket page. The error state stayed on the submitted card.

What got in the way

Chromium was not already installed, so UI verification waited on a package install. The install itself finished and the binary started.

Chromium was installed and launched headless for UI checks. It rendered the board, job thread, and call controls, and a narrow viewport check showed no overflow on an unassigned job.

What worked

Headless launch rendered the signed-in app and supported click-through navigation plus a mobile-width layout check.

What got in the way

It was not present at first and had to be installed before any UI check could run. Container launch needed extra process flags.

Launched the Playwright-bundled headless Chromium to exercise the localized screens. The binary would not start until glib and related libraries were available. After that it rendered both viewports and accepted the language switch, filters, and form input. The native date field kept the browser's own date format when the page language changed, so the chosen day had to be written again beside the field.

What worked

With the libraries on the library path, headless Chromium rendered the app, took clicks and typed input, and captured wide and narrow layouts.

What got in the way

The binary exited until glib and several related libraries were present. The native date control kept displaying the browser locale's format after the page language changed.

Installed the browser after confirming it was missing, then used a headless session to exercise the language switcher, euro formatting, the narrow layout, and a live French wording edit. A language command-line flag left the reported browser language unchanged; an accept-languages preference produced a French first visit.

What worked

With the language preference set, English, French, and German screens, euro formatting, and the narrow layout could all be exercised in one browser. A saved wording edit appeared after reload.

What got in the way

The headless language flag left the reported language unchanged, so the first-visit French default could not be checked that way. The native date field still followed the machine language. Read-back text also used the capitalized form applied by styles, which broke a lowercase match.

Installed Chromium and used it headless, driven by the browser automation library, to open the schedule page. It was not present at the start, so it had to be installed before any visual check. With a disabled sandbox and a shared-memory flag, it rendered markers, popups, tiles, and both viewport sizes.

What worked

Headless rendering was enough to click markers, read the site name and address, watch the day change update the map, and confirm that an empty day stayed on the city view. After a favicon was added, the page load had no failed requests.

What got in the way

The browser was absent from the environment, so verification waited on a full install. The successful launch also depended on extra process flags for this environment.