fix: a slow answer to an approval still reaches the site (closes #540)
check / check (push) Waiting to run
e2e / e2e-chrome (push) Waiting to run
e2e / e2e-firefox (push) Waiting to run

Chrome stopped the background worker about six minutes after a site's
request even with the approval window open, and the approval and the
site's waiting request went with it. Every approval is now added through
addPendingApproval(), which starts a timer in the worker that calls
runtime.getPlatformInfo() every 20 seconds while any approval is
pending; Chrome counts each call as activity.

tests/e2e/slowApproval.js, run by make test-e2e, leaves a transaction
and a signature approval open for seven minutes in minimized windows and
requires the site to receive both results. It drives Chromium over the
DevTools pipe because Playwright keeps DevTools attached to the worker.
Its loopback dApp server, shared with the Firefox suite, moves to
tests/e2e/dapp.js.

Model: opus-5-5
This commit was merged in pull request #553.
This commit is contained in:
2026-10-16 03:27:53 +02:00
parent bad6494e43
commit f9f32ab32d
11 changed files with 714 additions and 52 deletions
+1 -1
View File
@@ -94,7 +94,7 @@ function word(value) {
// is the real inpage provider and not a copy the harness wired up.
//
// DAPP_HTML below is exported and served verbatim by the Firefox suite too
// (tests/e2e/firefox/dapp.js), from a loopback origin rather than through a
// (tests/e2e/dapp.js), from a loopback origin rather than through a
// route handler. The two suites drive different browsers over different
// protocols, but the page they drive — the __dapp API, the message log — is
// one fixture, so an assertion written against it means the same thing on