mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 10:59:59 +00:00
kevinveenbirkenbachandClaude Opus 5.5
373d5c9dc7
The shared Playwright config passes --unsafely-treat-insecure-origin-as-secure for every .onion origin in the environment, but Playwright's default chrome-headless-shell ignores that switch. On the tor axis the odoo origin therefore stayed an insecure context: navigator.clipboard was undefined and Odoo 20's onboarding tour crashed with "Cannot read properties of undefined (reading 'writeText')" and "Cannot destructure property 'TourInteractive'", opening error dialogs that the addon specs read as a missing module (odoo#2, swarm tor, main run 38038541631). When ODOO_BASE_URL is an onion URL the odoo specs now use channel "chromium", the full Chromium build in the Playwright image, and block service workers; clearnet runs keep every option unchanged. The worker is blocked because a secure context lets Odoo register /web/service-worker.js, whose fetch handler answers a failed navigation with a cached page or /odoo/offline: gotoOnion would get a 200 instead of the transport error it retries on. The switch stays in the role: a use.channel in the shared config would also reach the Firefox launch of onion-test.js, which rejects it with "Unsupported firefox channel", and would move every other role's onion run to a browser none of them was tested on. Verified with Playwright 1.63 in the runner's staging layout and the real odoo specs: an onion ODOO_BASE_URL resolves channel "chromium" and serviceWorkers "block", also for the contexts _shared.js creates itself, and launches chromium-<rev>/chrome-linux64/chrome; a clearnet one, and HEAD's specs on onion, keep the headless shell and "allow". All spec files stay on one worker, which the suite's one-worker test requires. Against Odoo 20's service worker with a dropped connection, full Chromium returned the cached /odoo page with status 200, while with the worker blocked page.goto threw net::ERR_CONNECTION_FAILED as the headless shell does. In the v1.64.0 image full Chromium made no :443 attempt to an onion host and the onion origin reported isSecureContext with crypto.subtle, which the headless shell did not. A local deploy of web-app-odoo variant 2 over Tor ran the odoo suite on /ms-playwright/chromium-1248/chrome-linux64/chrome and passed all seven addon specs, the one-worker test and the guest flow without a retry; in the variant 0 round the suites of the other roles kept chrome-headless-shell. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>