clawbot
5e00956236
All checks were successful
check / check (push) Successful in 30s
Drives the real popup in a real Firefox with dist/firefox/ installed as an unpacked MV2 temporary add-on, via geckodriver. Covers popup load, wallet creation through the UI, and the Add Token screen. Outside make check, like the Chrome suite. Zero npm dependencies: tests/e2e/firefox/driver.js is a WebDriver client over global fetch and child_process against geckodriver's HTTP API. The Dockerfile pins the node base image, the Firefox 153.0.3 tarball and geckodriver 0.36.0 by digest. Errors are read from the privileged nsIConsoleService in Marionette's chrome context, filtered to non-warning entries whose sourceName is the extension origin. BiDi log.entryAdded delivers nothing at all for extension pages, so a Playwright-BiDi or Puppeteer-BiDi harness would see nothing and report success; the code says so where someone would be tempted to simplify it. Errors logged during add-on install and background startup are drained and folded into step 1, never discarded: a throw at the top of src/background/index.js kills the background page and fails the run. Content-script capture is left as unverified, because --network none leaves no http:// page for a content script to be injected into. Each drain reads the console and clears it in ONE chrome script. Splitting the read from Services.console.reset() left a window between the two round trips in which an error was logged into a buffer about to be discarded, and destroyed unread rather than deferred to the next drain; a probe of 100 sequenced throws at 20ms spacing lost one. With the drain atomic the same probe accounts for every throw that falls inside the observed window, on two consecutive runs. No driver layer is shared with the Chrome suite and the three UI steps are written twice deliberately: the two backends have no common substrate, and three steps do not pay for a shim. Two limits are documented rather than papered over, with measurements rather than absolutes. Error capture is poll-based, so an error is attributed to a step and not to a moment within it; the drained window ends ~1.5s after the last step returns (a 500ms settle, a 1000ms sleep and two drain round trips), and that cut-off jitters run to run — three runs of throws at fixed offsets reported everything up to +1.5s and one of the three also reported +1.6s. Inside the window the atomic drain leaves no race, but nsIConsoleService keeps a ring buffer of only 250 messages, so more than 250 console messages between two drains evicts unread errors: 400 throws inside one step report as exactly the newest 250, on three runs, while occupancy in a clean run peaks at 4 of 250 at the install drain and 0 at every later drain. Nothing is stubbed; the container runs with --network none instead, which proves no request escaped, cannot report which were attempted, and runs only the failure branches of network-dependent code.
16 KiB
16 KiB