POPUP_VIEWPORT in tests/e2e/run.js said 360x600, but body in src/popup/styles/main.css is 396px wide and openApprovalWindow() in src/background/index.js opens an approval window at 396x600. It is now 396x600, defined once at the top of the file, and the frame in the hostile token symbol test takes its size from it. The comments in src/popup/index.html and tests/dustThreshold.test.js that said 360x600 now say 396x600. README already gave the real size.
assertAddressesFit() now measures the page at 396x600, then puts back the size the page had, so no later step's size depends on whether it ran. Every page it measured was 1280x720, where a page never scrolls sideways, so its check that the popup does not scroll sideways could not fail. That covers the address layout tests for #380 (the wallet list, Home, and the address, receive, send, token and transaction detail screens), the confirmation screen in goToConfirm(), the site-connection prompt and the transaction approval. Shown locally, not pushed: with body widened to 420px, each of those checks finds the popup scrolling sideways by 24px.
What the diff does not show:
Headless Chromium gives an approval window 1280x720 whatever size the extension asks for. The size is set on the page, not the window, so the window's frame and the page widening its window are still checked by the Firefox suite only. README's list of what the Chrome suite leaves out says this.
Judgement call: the README bullet is outside the plan's file list; without it README would say Chrome checks no approval's width.
Model: opus-5-5
`POPUP_VIEWPORT` in `tests/e2e/run.js` said 360x600, but `body` in `src/popup/styles/main.css` is 396px wide and `openApprovalWindow()` in `src/background/index.js` opens an approval window at 396x600. It is now 396x600, defined once at the top of the file, and the frame in the hostile token symbol test takes its size from it. The comments in `src/popup/index.html` and `tests/dustThreshold.test.js` that said 360x600 now say 396x600. README already gave the real size.
`assertAddressesFit()` now measures the page at 396x600, then puts back the size the page had, so no later step's size depends on whether it ran. Every page it measured was 1280x720, where a page never scrolls sideways, so its check that the popup does not scroll sideways could not fail. That covers the address layout tests for https://git.eeqj.de/sneak/AutistMask/issues/380 (the wallet list, Home, and the address, receive, send, token and transaction detail screens), the confirmation screen in `goToConfirm()`, the site-connection prompt and the transaction approval. Shown locally, not pushed: with `body` widened to 420px, each of those checks finds the popup scrolling sideways by 24px.
What the diff does not show:
- Headless Chromium gives an approval window 1280x720 whatever size the extension asks for. The size is set on the page, not the window, so the window's frame and the page widening its window are still checked by the Firefox suite only. README's list of what the Chrome suite leaves out says this.
Judgement call: the README bullet is outside the plan's file list; without it README would say Chrome checks no approval's width.
Model: opus-5-5
Added: the site-connection prompt's sideways-scroll check in the eth_requestAccounts approved test now sets the page to 396x600 before measuring, as the transaction approval's does, and README's Chrome-suite limits name both.
Model: opus-5-5
Added: the site-connection prompt's sideways-scroll check in the `eth_requestAccounts` approved test now sets the page to 396x600 before measuring, as the transaction approval's does, and README's Chrome-suite limits name both.
Model: opus-5-5
tests/dustThreshold.test.js, the comment above "reserves its height in the markup", still says the browser tests measure the flash line "at the documented 360x600 popup". Those tests now run at 396x600, and README gives 396x600. Acceptable: the comment says 396x600.
tests/e2e/run.js: the address layout tests for #380 still call assertAddressesFit() on the popup's own screens at Playwright's 1280x720 default. These are the wallet list, Home, and the address, receive, send and transaction detail screens, plus the confirmation screen in goToConfirm(). Its check that the popup does not scroll sideways cannot fail there. This is the same fault the PR fixes for the two approval prompts, and the issue says the tests must use the popup's real size. Acceptable: those pages are set to POPUP_VIEWPORT before they are measured, and each check is shown to fail with body widened. At the least, README's list of what the Chrome suite leaves out must say these screens are measured at 1280x720, where that check cannot fail.
tests/e2e/run.js, the new comment in the eth_sendTransaction approved test: it says headless Chromium opens the window at 1280x720, "So it is measured at the size the window is opened at". Read literally, that size is 1280x720, which is the opposite of what the next line does. Acceptable: the comment names the size it measures at, the 396x600 the extension asks for (POPUP_VIEWPORT).
Judgement call: the dated entries under Completed Steps in TODO.md and the hostile-symbol strings that tests/htmlEscape.test.js and tests/balanceLineEscaping.test.js quote word for word from an issue still say 360. They record history or quote an issue rather than give the popup's size, so they are not findings.
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. `tests/dustThreshold.test.js`, the comment above "reserves its height in the markup", still says the browser tests measure the flash line "at the documented 360x600 popup". Those tests now run at 396x600, and README gives 396x600. Acceptable: the comment says 396x600.
2. `tests/e2e/run.js`: the address layout tests for https://git.eeqj.de/sneak/AutistMask/issues/380 still call `assertAddressesFit()` on the popup's own screens at Playwright's 1280x720 default. These are the wallet list, Home, and the address, receive, send and transaction detail screens, plus the confirmation screen in `goToConfirm()`. Its check that the popup does not scroll sideways cannot fail there. This is the same fault the PR fixes for the two approval prompts, and the issue says the tests must use the popup's real size. Acceptable: those pages are set to `POPUP_VIEWPORT` before they are measured, and each check is shown to fail with `body` widened. At the least, README's list of what the Chrome suite leaves out must say these screens are measured at 1280x720, where that check cannot fail.
3. `tests/e2e/run.js`, the new comment in the `eth_sendTransaction` approved test: it says headless Chromium opens the window at 1280x720, "So it is measured at the size the window is opened at". Read literally, that size is 1280x720, which is the opposite of what the next line does. Acceptable: the comment names the size it measures at, the 396x600 the extension asks for (`POPUP_VIEWPORT`).
Judgement call: the dated entries under Completed Steps in `TODO.md` and the hostile-symbol strings that `tests/htmlEscape.test.js` and `tests/balanceLineEscaping.test.js` quote word for word from an issue still say 360. They record history or quote an issue rather than give the popup's size, so they are not findings.
Model: opus-5-5
Fixed in full: assertAddressesFit() sets the page it measures to POPUP_VIEWPORT first, so all of those screens are measured at 396x600; with body widened to 420px (local, not pushed), each finds the popup scrolling sideways by 24px.
Fixed: that comment went with the sizing line it explained; the comment on assertAddressesFit() names 396x600 (POPUP_VIEWPORT) as the size it measures at.
Judgement call: the size is set inside assertAddressesFit() rather than at each caller, so the page keeps 396x600 after it is measured.
Model: opus-5-5
1. Fixed: the comment says 396x600.
2. Fixed in full: `assertAddressesFit()` sets the page it measures to `POPUP_VIEWPORT` first, so all of those screens are measured at 396x600; with `body` widened to 420px (local, not pushed), each finds the popup scrolling sideways by 24px.
3. Fixed: that comment went with the sizing line it explained; the comment on `assertAddressesFit()` names 396x600 (`POPUP_VIEWPORT`) as the size it measures at.
Judgement call: the size is set inside `assertAddressesFit()` rather than at each caller, so the page keeps 396x600 after it is measured.
Model: opus-5-5
tests/e2e/run.js, assertAddressesFit(): it sets the page to 396x600 and leaves it there, so on the shared popup page the size every later step and test runs at depends on which tests ran before it and whether the popup was reopened since. The check that the password field and Sign & Send do not move runs at 396x600 in the test for #583, but at 1280x720 in the same check for #609, because that test reopens the popup after goToConfirm(). The #238 test "nothing moves when the balance arrives" never calls assertAddressesFit(), and runs at 396x600 only because an earlier test did. None of these tests says what size it runs at, and removing or reordering a test changes it for the others. Acceptable: no test's size depends on an earlier step. Either assertAddressesFit() puts the page back to the size it found, or every popup and approval page gets POPUP_VIEWPORT when it opens, so the whole suite runs at that size. The PR body and README follow whichever is chosen.
Unverified: the two comments in src/popup/index.html that say a layout change would push Import below the fold at 396x600 were not checked with the markup changed. The Import position measured at 396x600 is consistent with both.
Model: opus-5-5
**Review: FAIL (`needs-rework`)**
1. `tests/e2e/run.js`, `assertAddressesFit()`: it sets the page to 396x600 and leaves it there, so on the shared popup page the size every later step and test runs at depends on which tests ran before it and whether the popup was reopened since. The check that the password field and Sign & Send do not move runs at 396x600 in the test for https://git.eeqj.de/sneak/AutistMask/issues/583, but at 1280x720 in the same check for https://git.eeqj.de/sneak/AutistMask/issues/609, because that test reopens the popup after `goToConfirm()`. The https://git.eeqj.de/sneak/AutistMask/issues/238 test "nothing moves when the balance arrives" never calls `assertAddressesFit()`, and runs at 396x600 only because an earlier test did. None of these tests says what size it runs at, and removing or reordering a test changes it for the others. Acceptable: no test's size depends on an earlier step. Either `assertAddressesFit()` puts the page back to the size it found, or every popup and approval page gets `POPUP_VIEWPORT` when it opens, so the whole suite runs at that size. The PR body and README follow whichever is chosen.
Unverified: the two comments in `src/popup/index.html` that say a layout change would push Import below the fold at 396x600 were not checked with the markup changed. The Import position measured at 396x600 is consistent with both.
Model: opus-5-5
POPUP_VIEWPORT in tests/e2e/run.js said 360x600, while body in
src/popup/styles/main.css is 396px wide and the background opens an
approval window at 396x600. It is now 396x600, defined once near the top
of the file, and the hostile token symbol's frame takes its size from it.
assertAddressesFit() now measures the page at that size, then puts back
the size it found. Every page it measured, the popup's own screens and the
two approval prompts, was 1280x720, where a page never scrolls sideways,
so its sideways-scroll check could not fail. README's list of what the
Chrome suite leaves out says what sizing the page does not cover.
Comments in src/popup/index.html and tests/dustThreshold.test.js that
said 360x600 now say 396x600.
Model: opus-5-5
Fixed: assertAddressesFit() saves the page's size, measures at 396x600 (POPUP_VIEWPORT), then puts the saved size back, so every test runs at 1280x720 apart from that measurement, whatever ran before it; README's Chrome-suite bullet and the PR body say so.
Model: opus-5-5
1. Fixed: `assertAddressesFit()` saves the page's size, measures at 396x600 (`POPUP_VIEWPORT`), then puts the saved size back, so every test runs at 1280x720 apart from that measurement, whatever ran before it; README's Chrome-suite bullet and the PR body say so.
Model: opus-5-5
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.
POPUP_VIEWPORTintests/e2e/run.jssaid 360x600, butbodyinsrc/popup/styles/main.cssis 396px wide andopenApprovalWindow()insrc/background/index.jsopens an approval window at 396x600. It is now 396x600, defined once at the top of the file, and the frame in the hostile token symbol test takes its size from it. The comments insrc/popup/index.htmlandtests/dustThreshold.test.jsthat said 360x600 now say 396x600. README already gave the real size.assertAddressesFit()now measures the page at 396x600, then puts back the size the page had, so no later step's size depends on whether it ran. Every page it measured was 1280x720, where a page never scrolls sideways, so its check that the popup does not scroll sideways could not fail. That covers the address layout tests for #380 (the wallet list, Home, and the address, receive, send, token and transaction detail screens), the confirmation screen ingoToConfirm(), the site-connection prompt and the transaction approval. Shown locally, not pushed: withbodywidened to 420px, each of those checks finds the popup scrolling sideways by 24px.What the diff does not show:
Judgement call: the README bullet is outside the plan's file list; without it README would say Chrome checks no approval's width.
Model: opus-5-5
4a94ba756eto4f93392799Added: the site-connection prompt's sideways-scroll check in the
eth_requestAccountsapproved test now sets the page to 396x600 before measuring, as the transaction approval's does, and README's Chrome-suite limits name both.Model: opus-5-5
Review: FAIL (
needs-rework)tests/dustThreshold.test.js, the comment above "reserves its height in the markup", still says the browser tests measure the flash line "at the documented 360x600 popup". Those tests now run at 396x600, and README gives 396x600. Acceptable: the comment says 396x600.tests/e2e/run.js: the address layout tests for #380 still callassertAddressesFit()on the popup's own screens at Playwright's 1280x720 default. These are the wallet list, Home, and the address, receive, send and transaction detail screens, plus the confirmation screen ingoToConfirm(). Its check that the popup does not scroll sideways cannot fail there. This is the same fault the PR fixes for the two approval prompts, and the issue says the tests must use the popup's real size. Acceptable: those pages are set toPOPUP_VIEWPORTbefore they are measured, and each check is shown to fail withbodywidened. At the least, README's list of what the Chrome suite leaves out must say these screens are measured at 1280x720, where that check cannot fail.tests/e2e/run.js, the new comment in theeth_sendTransactionapproved test: it says headless Chromium opens the window at 1280x720, "So it is measured at the size the window is opened at". Read literally, that size is 1280x720, which is the opposite of what the next line does. Acceptable: the comment names the size it measures at, the 396x600 the extension asks for (POPUP_VIEWPORT).Judgement call: the dated entries under Completed Steps in
TODO.mdand the hostile-symbol strings thattests/htmlEscape.test.jsandtests/balanceLineEscaping.test.jsquote word for word from an issue still say 360. They record history or quote an issue rather than give the popup's size, so they are not findings.Model: opus-5-5
4f93392799to09e645454509e6454545tof8f20155abassertAddressesFit()sets the page it measures toPOPUP_VIEWPORTfirst, so all of those screens are measured at 396x600; withbodywidened to 420px (local, not pushed), each finds the popup scrolling sideways by 24px.assertAddressesFit()names 396x600 (POPUP_VIEWPORT) as the size it measures at.Judgement call: the size is set inside
assertAddressesFit()rather than at each caller, so the page keeps 396x600 after it is measured.Model: opus-5-5
Review: FAIL (
needs-rework)tests/e2e/run.js,assertAddressesFit(): it sets the page to 396x600 and leaves it there, so on the shared popup page the size every later step and test runs at depends on which tests ran before it and whether the popup was reopened since. The check that the password field and Sign & Send do not move runs at 396x600 in the test for #583, but at 1280x720 in the same check for #609, because that test reopens the popup aftergoToConfirm(). The #238 test "nothing moves when the balance arrives" never callsassertAddressesFit(), and runs at 396x600 only because an earlier test did. None of these tests says what size it runs at, and removing or reordering a test changes it for the others. Acceptable: no test's size depends on an earlier step. EitherassertAddressesFit()puts the page back to the size it found, or every popup and approval page getsPOPUP_VIEWPORTwhen it opens, so the whole suite runs at that size. The PR body and README follow whichever is chosen.Unverified: the two comments in
src/popup/index.htmlthat say a layout change would push Import below the fold at 396x600 were not checked with the markup changed. The Import position measured at 396x600 is consistent with both.Model: opus-5-5
f8f20155abtoc53ad6c823assertAddressesFit()saves the page's size, measures at 396x600 (POPUP_VIEWPORT), then puts the saved size back, so every test runs at 1280x720 apart from that measurement, whatever ran before it; README's Chrome-suite bullet and the PR body say so.Model: opus-5-5
Review: PASS
Model: opus-5-5