The mechanism fits in a sentence. A print stylesheet has to hide the capture container on screen, hiding it means a `display:none` subtree, and by the author's account the `decode()` promise on an image inside such a subtree never resolves [5]. `printCanvas` awaited that promise once per encoded slice, so the command sat on an await with no path to settling, and no dialog ever appeared [4][5].
For that to bite you, two things have to be true at once: your print path builds its own hidden container, and something inside it awaits image decoding instead of painting. The writeup treats the non-resolving decode as a fact about Firefox that the author would otherwise have to keep being right about [9]. It tests nothing else, so it says nothing about what a Chromium build does with the same call. The extension's source is not public [2], which makes this a report you can reason from rather than rerun.
The options considered were stopping the await on `decode()`, moving the container out of the hidden subtree until decoding finishes, or dropping the blob URLs and appending canvas elements directly, which paint synchronously and leave nothing to decode and no object URL to revoke [8][9]. The first two make printing work and leave the component's correctness resting on that Firefox behaviour [9]. The third option eliminates the question altogether. Picking the third required knowing the cause, and as the author puts it, a green suite that goes green again is not evidence of which fix you applied [10].
The same batch produced a second failure one level in. Choosing PDF broke "Open in editor" because `deliver()` handed the editor a PDF blob and `createImageBitmap` cannot decode one; both stages had tests, the seam between them did not [7]. The author's generalisation is that every bug the project has produced has lived at a boundary, either his code to a browser API or one stage to another, and that a suite of pure functions cannot represent a boundary at all [17]. The six Node suites cover band arithmetic, canvas dimension limits, filename sanitising, the background module graph under stubbed extension APIs, PDF structure and scan geometry [6]. Those 130 assertions were correct answers to other questions, and printing simply was not among them.
`test-pages/harness.html` runs the options page and the print pipeline against stubbed extension APIs, with storage backed by a plain object and `window.print` intercepted so the real page logic runs unmodified [11]. Thirteen checks, one tenth the assertion count of the Node suites [16], and it caught the total print failure on its first run [11].
What matters is that the harness was fed an injected hang and reported "timed out after 8s" [12] rather than the raw count of thirteen checks, because a test never shown to fail cannot be distinguished from a test that cannot fail, and a harness for a hang is the case most likely to silently do nothing [14]. Every check is timeout-bounded so a hang reports rather than truncating the run, and imports are cache-busted after a stale cached module made an already-fixed file look broken and cost more time than the bug had [13].
The OCR harness shows the payoff of asserting against pixels: 13 of 13 words recognised, mean confidence 95, digits included, and word boxes landing where the text was drawn [15]. No wrapper unit test can assert that last part, because it never drew anything.
