fix: declare toolbar icons and ship real PNGs in both archives (closes #371)
Neither manifest declared an `icons` block, so Chrome and Firefox both drew the generic puzzle piece for this extension. That is the first thing the owner sees on every launch, and an unbranded placeholder is also how a user fails to tell a real extension from a look-alike. Both manifests now declare 16/32/48/128 as `icons/icon<size>.png`, and the four PNGs live at `icons/` in the tree. build.js copies them into each browser directory relative to it, so nothing points up and out the way `dist/styles.css` does, and the receipt records them like every other emitted file. The sizes copied come from the manifest that will ship next to them, not from a second list in build.js: a size a manifest declares and `icons/` does not hold fails the build with the path that is missing, rather than emitting a directory whose manifest references nothing. script/lib/package.js already resolved `.png` strings, so an icon that reached a manifest but not the archive fails self-containment; tests/packaging.test.js now pins that case, since it was covered only incidentally before. tests/manifest.test.js asserts the declaration in both manifests, that both declare the same set, and that each referenced file is a PNG whose IHDR states the size the entry claims — a declaration alone would still permit a reference to a file that is not there or is not an image. The artwork is original, drawn from geometry rather than traced or downloaded: a flat dark-navy rounded square (#101A2E) with a teal (#35E0C2) triangular "A" — one outer triangle minus a triangular counter — rasterised with 8x8 supersampling and encoded as RGBA PNG. One shape, two flat colours, which is what a 16px toolbar slot can carry. Verified: make check 56 suites / 1023 tests, make build and make package green, both archives unpacked and the four icons confirmed inside each with bytes identical to the tree, make test-e2e 55/55 and 5/5, make test-e2e-firefox 8/8 and 7/7 (the latter installs the packaged XPI). Removing icons/icon48.png fails make build; making build.js skip one copy fails make package with "the chrome archive would not be self-contained: it is told to load icons/icon48.png, which is not in it".
This commit is contained in:
12
TODO.md
12
TODO.md
@@ -45,6 +45,18 @@ but the review is broader than any of them.
|
||||
|
||||
# Completed Steps
|
||||
|
||||
- 2026-08-23: Both manifests declare toolbar icons, and real PNGs at
|
||||
16/32/48/128 ship inside both archives
|
||||
([#371](https://git.eeqj.de/sneak/AutistMask/issues/371)). Neither manifest
|
||||
had an `icons` block, so both browsers drew a generic puzzle piece — the first
|
||||
thing the owner sees on every launch, and how a user tells a real extension
|
||||
from a look-alike. The sizes `build.js` copies into each browser directory are
|
||||
read out of the manifest that ships next to them rather than from a second
|
||||
list, so a declared size `icons/` does not hold fails `make build`;
|
||||
`script/lib/package.js` already resolves `.png` references, so an icon that
|
||||
reached a manifest but not the archive fails packaging. The artwork is
|
||||
original: a flat dark-navy rounded field with a teal triangular "A", drawn
|
||||
from geometry and rasterised into PNG, nothing traced or downloaded.
|
||||
- 2026-08-23: A swap amount and the token it is counted in now always come from
|
||||
the same hop, on both sides of the approval screen
|
||||
([#359](https://git.eeqj.de/sneak/AutistMask/issues/359) and
|
||||
|
||||
Reference in New Issue
Block a user