Action: file this as a bug upstream at Alpine aports — https://gitlab.alpinelinux.org/alpine/aports/-/issues — against community/chromium. This GitHub issue is the tracker/holding copy; the fix belongs in Alpine's packaging, not here.
Context: our build-chromium-headless-shell apk fast-path (Dockerfile.apk) is now superseded by the from-source build. Before dropping it entirely we should report the root-cause upstream so the community package becomes usable for Playwright/Puppeteer. The install itself works today (the earlier CI failure was transient edge churn during the flac-1.5 transition); the reportable defect is the UA-stylesheet, below.
Title (for the GitLab issue)
chromium-headless-shell: broken UA stylesheet — vanilla <div> renders as display:inline, form controls as appearance:none
Body
The chromium-headless-shell subpackage from community/chromium ships without the UA-stylesheet resources, so the browser does not apply HTML's default block/inline / form-control rendering rules. This makes the binary unusable as a drop-in replacement for upstream chrome-headless-shell in test automation (Playwright, Puppeteer, etc.).
Confirmed via local probe
docker run against the apk build at PW SDK + minimal launch (no PW config patching):
<div> (no styles): getComputedStyle(el).display → "inline" (expected "block")<p>, <h1>, <h2>, <article>, <section> — same<input type="checkbox">: computed appearance: "none" (expected "auto")<input type="checkbox"> boundingBox: {x:0,y:0,width:0,height:0} (expected 13×13)- Adding inline
appearance: auto !important restores the 13×13 native checkbox
In our PW conformance harness this manifests as ~150 page-suite failures with element is not visible after a locator resolves the element (looks like a timing bug, is a layout bug).
Artifact filesystem
chrome-headless-shell-linux64/ in the apk contains the binary, headless_lib_data.pak (745 KB), v8_context_snapshot.bin, musl loader, a few dozen lib*.so, locales/, vk_swiftshader_icd.json — and no resources/ directory. Upstream chrome-headless-shell ships the UA stylesheet (in chrome_100_percent.pak / sibling resource pak, ~7 MB) which is what makes <div> a block element.
Reference (proof it's packaging, not upstream chromium)
A from-source chromium-headless-shell build against the same Alpine sysroot with the standard resource-pak pipeline enabled does NOT exhibit the bug — <div> renders block, controls render at native UA size, and the ~150-test visibility cluster clears. Our from-source conformance is green (e.g. run https://github.com/jclaveau/ci-prebuilds/actions/runs/29780036867 , tag chs-fs-edge). So the regression is in the apk packaging / build flags, not chromium itself.
Suggested fix
- Ship the missing
resources/ directory + standard resource pak files alongside chrome-headless-shell in the subpackage, or
- Re-include the UA stylesheet content into
headless_lib_data.pak if a build flag dropped it.
Happy to test a patch.
Before filing at GitLab
Full working copy: .agents/requested-memory/alpine-apk-bug-draft.md.
Action: file this as a bug upstream at Alpine aports — https://gitlab.alpinelinux.org/alpine/aports/-/issues — against
community/chromium. This GitHub issue is the tracker/holding copy; the fix belongs in Alpine's packaging, not here.Context: our
build-chromium-headless-shellapk fast-path (Dockerfile.apk) is now superseded by the from-source build. Before dropping it entirely we should report the root-cause upstream so the community package becomes usable for Playwright/Puppeteer. The install itself works today (the earlier CI failure was transient edge churn during the flac-1.5 transition); the reportable defect is the UA-stylesheet, below.Title (for the GitLab issue)
chromium-headless-shell: broken UA stylesheet — vanilla<div>renders asdisplay:inline, form controls asappearance:noneBody
The
chromium-headless-shellsubpackage fromcommunity/chromiumships without the UA-stylesheet resources, so the browser does not apply HTML's default block/inline / form-control rendering rules. This makes the binary unusable as a drop-in replacement for upstream chrome-headless-shell in test automation (Playwright, Puppeteer, etc.).Confirmed via local probe
docker runagainst the apk build at PW SDK + minimal launch (no PW config patching):<div>(no styles):getComputedStyle(el).display→"inline"(expected"block")<p>,<h1>,<h2>,<article>,<section>— same<input type="checkbox">: computedappearance: "none"(expected"auto")<input type="checkbox">boundingBox:{x:0,y:0,width:0,height:0}(expected13×13)appearance: auto !importantrestores the 13×13 native checkboxIn our PW conformance harness this manifests as ~150 page-suite failures with
element is not visibleafter a locator resolves the element (looks like a timing bug, is a layout bug).Artifact filesystem
chrome-headless-shell-linux64/in the apk contains the binary,headless_lib_data.pak(745 KB),v8_context_snapshot.bin, musl loader, a few dozenlib*.so,locales/,vk_swiftshader_icd.json— and noresources/directory. Upstream chrome-headless-shell ships the UA stylesheet (inchrome_100_percent.pak/ sibling resource pak, ~7 MB) which is what makes<div>a block element.Reference (proof it's packaging, not upstream chromium)
A from-source chromium-headless-shell build against the same Alpine sysroot with the standard resource-pak pipeline enabled does NOT exhibit the bug —
<div>renders block, controls render at native UA size, and the ~150-test visibility cluster clears. Our from-source conformance is green (e.g. run https://github.com/jclaveau/ci-prebuilds/actions/runs/29780036867 , tagchs-fs-edge). So the regression is in the apk packaging / build flags, not chromium itself.Suggested fix
resources/directory + standard resource pak files alongsidechrome-headless-shellin the subpackage, orheadless_lib_data.pakif a build flag dropped it.Happy to test a patch.
Before filing at GitLab
<div>isblockcommunity/chromiummaintainer before taggingFull working copy:
.agents/requested-memory/alpine-apk-bug-draft.md.