chrome+firefox v0.3

README.md

@@ -19,7 +19,7 @@ Once it is published, from addons.mozilla.org. Until then, build it yourself:
 
 ```
 corepack pnpm install     # first time, or after a dependency change
-make xpi                  # typecheck, bundle, and package logsdu-<version>.xpi
+make xpi                  # typecheck, bundle, and package dist/logsdu-<version>.xpi
 ```
 
 `make xpi` prints the full path of the file and how to install it. The package
@@ -118,23 +118,56 @@ check.
 
 ## Chrome
 
-`make chrome` builds it. The only difference is the background key: Firefox MV3
-uses an event page, Chrome MV3 requires a service worker, so the manifest is
-generated per target rather than duplicated. Everything else -- `chrome.*`
-namespace, MV3, no Firefox-only APIs -- is already shared.
+```
+make chrome               # unpacked Chrome build in build/
+make crx                  # package it as dist/logsdu-<version>-chrome.zip
+```
 
-It has not been tested against Chrome. Do not assume it works.
+Load `build/` via `chrome://extensions` -> Developer mode -> **Load unpacked**,
+or upload the zip at
+[the Web Store dashboard](https://chrome.google.com/webstore/devconsole).
+
+One codebase, two manifests. Chrome MV3 requires a background *service worker*
+and rejects Firefox's event-page `background.scripts`; Firefox needs the gecko
+block that Chrome has no use for. `esbuild.config.mjs` writes the right manifest
+per target, so the port is a build flag rather than a fork. Everything else --
+the `chrome.*` namespace, MV3, the permission model -- is shared.
+
+Two things that differ in practice, both handled:
+
+- **Icons must be raster.** Chrome does not accept SVG in `icons`, so the PNGs
+  in `icons/` are generated from `logsdu.svg` and both browsers use those.
+- **Service workers have no `window` or `document`.** A stray reference through
+  a shared import would break Chrome only, silently, at runtime. `make smoke`
+  runs the built background bundle in a worker-shaped sandbox to catch that.
+
+What has been verified: Chrome 151 loads the build without errors, and the
+background bundle registers exactly one content script for exactly the
+configured origin. What has **not** been verified is a real login against a live
+portal in Chrome.
+
+A caveat that applies to both browsers: the page-world filler is injected as a
+`<script src>` tag, which a site's Content-Security-Policy can refuse. Portals
+that send no CSP -- the common case for this kind of form -- are unaffected. A
+portal that does would need the filler registered as a `MAIN` world content
+script instead.
 
 ## Development
 
 ```
 corepack pnpm install
 make test                 # unit tests
+make smoke                # background bundle under a service worker
 make                      # typecheck and bundle into build/
+make packages             # both publishable packages into dist/
 corepack pnpm run dev     # rebuild on change
 make clean
 ```
 
+`build/` is the unpacked extension and is regenerated from scratch every time.
+`dist/` holds the packages meant to be published, and is kept separate so that
+packaging never tries to include its own output.
+
 While iterating, load the unpacked directory rather than reinstalling an `.xpi`
 each time: `about:debugging` -> **This Firefox** -> **Load Temporary Add-on** ->
 `build/manifest.json`, then press **Reload** there after each rebuild. That copy
@@ -156,6 +189,7 @@ still needs the Reload click to pick anything up.
 | `src/config.ts` | Stored values, the rate limit and the logout cooldown |
 | `src/format.ts` | Input normalisers for the three masked fields |
 | `src/options.*`, `src/popup.*` | The two bits of UI |
+| `tools/sw-smoke.mjs` | Checks the background bundle survives a service worker |
 
 ### Why two scripts instead of one