README.md, in the End-to-End Tests section, lists as one of three standing limits of the dApp coverage:
> And the EIP-1193 error code does not survive the last hop: the rejection that crosses the boundary carries code 4001 and is asserted to, but src/content/inpage.js rebuilds it as new Error(message), so the calling page catches an error with no code property.
That stopped being true when #274 landed on next as 9dcd875. The provider now rejects with a ProviderRpcError carrying code, and the e2e suite asserts it on the page as well as on the wire — a current run of make test-e2e prints, for all four rejected flows:
# eth_requestAccounts rejection: code 4001 on the wire and on the page's ProviderRpcError
The commit did not touch README.md. So the file now advertises a defect the wallet does not have, in the section a reader consults to learn what the browser suites do and do not prove — the worst place for it, since the paragraph's whole job is to be the honest limits list.
Fix is the paragraph, not the code: delete the third limit and leave the other two, which are still accurate.
Found while wiring the suites into CI for #259; not fixed there, since it is outside that issue's scope.
`README.md`, in the End-to-End Tests section, lists as one of three standing limits of the dApp coverage:
> And the EIP-1193 error code does not survive the last hop: the rejection that crosses the boundary carries code 4001 and is asserted to, but `src/content/inpage.js` rebuilds it as `new Error(message)`, so the calling page catches an error with no `code` property.
That stopped being true when https://git.eeqj.de/sneak/AutistMask/issues/274 landed on `next` as `9dcd875`. The provider now rejects with a `ProviderRpcError` carrying `code`, and the e2e suite asserts it on the page as well as on the wire — a current run of `make test-e2e` prints, for all four rejected flows:
# eth_requestAccounts rejection: code 4001 on the wire and on the page's ProviderRpcError
The commit did not touch `README.md`. So the file now advertises a defect the wallet does not have, in the section a reader consults to learn what the browser suites do and do not prove — the worst place for it, since the paragraph's whole job is to be the honest limits list.
Fix is the paragraph, not the code: delete the third limit and leave the other two, which are still accurate.
Found while wiring the suites into CI for https://git.eeqj.de/sneak/AutistMask/issues/259; not fixed there, since it is outside that issue's scope.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
README.md, in the End-to-End Tests section, lists as one of three standing limits of the dApp coverage:> And the EIP-1193 error code does not survive the last hop: the rejection that crosses the boundary carries code 4001 and is asserted to, but
src/content/inpage.jsrebuilds it asnew Error(message), so the calling page catches an error with nocodeproperty.That stopped being true when #274 landed on
nextas9dcd875. The provider now rejects with aProviderRpcErrorcarryingcode, and the e2e suite asserts it on the page as well as on the wire — a current run ofmake test-e2eprints, for all four rejected flows:The commit did not touch
README.md. So the file now advertises a defect the wallet does not have, in the section a reader consults to learn what the browser suites do and do not prove — the worst place for it, since the paragraph's whole job is to be the honest limits list.Fix is the paragraph, not the code: delete the third limit and leave the other two, which are still accurate.
Found while wiring the suites into CI for #259; not fixed there, since it is outside that issue's scope.
clawbot referenced this issue2026-08-17 08:11:00 +02:00