The browser suites' wait for a screen passed as soon as the element laid out. Every view in the popup starts with the hidden class, and only the page's stylesheet makes that class hide anything, so until the stylesheet has applied every view lays out. An approval test could then read the prompt before the page's script had filled it: the empty network switch prompt seen on #501.
visible() in tests/e2e/harness.js and waitVisible() in tests/e2e/firefox/driver.js now also wait for the page to finish loading, which happens only after its stylesheet, and for neither the element nor anything around it to carry hidden, which showView() keeps on every view but the current one. The popup does not expose its current view to the page, so that class is what the harness reads. No caller and no extension code changed.
How the race was confirmed: a throwaway, uncommitted edit had the test route handler serve the popup's stylesheet 3 seconds late in approval windows only. Without the fix six approval tests failed, among them the network switch test with {"origin":"","current":"","requested":""}; with the fix the same run passed.
Worth knowing:
The Chrome wait no longer uses the browser library's own visibility check; it checks layout and the element's computed visibility itself, as the Firefox wait now also does, polls every 50ms, and a timeout names the selector.
Disclosure: the race was reproduced in Chrome only; the Firefox change follows from the same wait on the same page.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/502.
The browser suites' wait for a screen passed as soon as the element laid out. Every view in the popup starts with the `hidden` class, and only the page's stylesheet makes that class hide anything, so until the stylesheet has applied every view lays out. An approval test could then read the prompt before the page's script had filled it: the empty network switch prompt seen on https://git.eeqj.de/sneak/AutistMask/pulls/501.
`visible()` in `tests/e2e/harness.js` and `waitVisible()` in `tests/e2e/firefox/driver.js` now also wait for the page to finish loading, which happens only after its stylesheet, and for neither the element nor anything around it to carry `hidden`, which `showView()` keeps on every view but the current one. The popup does not expose its current view to the page, so that class is what the harness reads. No caller and no extension code changed.
How the race was confirmed: a throwaway, uncommitted edit had the test route handler serve the popup's stylesheet 3 seconds late in approval windows only. Without the fix six approval tests failed, among them the network switch test with `{"origin":"","current":"","requested":""}`; with the fix the same run passed.
Worth knowing:
- The Chrome wait no longer uses the browser library's own visibility check; it checks layout and the element's computed `visibility` itself, as the Firefox wait now also does, polls every 50ms, and a timeout names the selector.
Disclosure: the race was reproduced in Chrome only; the Firefox change follows from the same wait on the same page.
Model: opus-5-5
tests/e2e/harness.js:347-353: visible() replaced the browser library's own visibility check with a layout check, and the replacement no longer catches an element hidden with visibility: hidden. The popup hides about thirty elements that way (the invisible class and style.visibility, for example the fee block and the warnings on the confirmation screen), so visible() on any of them now passes while the page hides it. No current caller waits on such an element, but the helper promises to wait until the page shows the element, and the old check covered this case. Acceptable: the in-page check also requires the element's computed visibility to be visible (or the new wait is followed by the library's own visible-state wait), so the Chrome wait loses nothing the old one caught.
Model: opus-5-5
FAIL
1. `tests/e2e/harness.js:347-353`: `visible()` replaced the browser library's own visibility check with a layout check, and the replacement no longer catches an element hidden with `visibility: hidden`. The popup hides about thirty elements that way (the `invisible` class and `style.visibility`, for example the fee block and the warnings on the confirmation screen), so `visible()` on any of them now passes while the page hides it. No current caller waits on such an element, but the helper promises to wait until the page shows the element, and the old check covered this case. Acceptable: the in-page check also requires the element's computed `visibility` to be `visible` (or the new wait is followed by the library's own visible-state wait), so the Chrome wait loses nothing the old one caught.
Model: opus-5-5
The browser suites' wait for a screen passed as soon as the element laid
out. Until the page's stylesheet has applied, every view lays out, so an
approval test could read the prompt before the page's script had filled
it. visible() in the Chrome harness and waitVisible() in the Firefox
driver now also wait for the page to finish loading and for neither the
element nor anything around it to carry the hidden class that showView()
keeps on every view but the current one. Both also require the element's
computed visibility to be visible, as the browser library's own check in
Chrome did. No caller changed.
Model: opus-5-5
Fixed: visible() now also requires the element's computed visibility to be visible; waitVisible() in the Firefox driver had the same gap and carries the same line.
Disclosure: the Firefox driver's isVisible(), which is not a wait, still checks layout only; left alone as outside this finding.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/504#issuecomment-133727:
1. Fixed: `visible()` now also requires the element's computed `visibility` to be `visible`; `waitVisible()` in the Firefox driver had the same gap and carries the same line.
Disclosure: the Firefox driver's `isVisible()`, which is not a wait, still checks layout only; left alone as outside this finding.
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.
Closes #502.
The browser suites' wait for a screen passed as soon as the element laid out. Every view in the popup starts with the
hiddenclass, and only the page's stylesheet makes that class hide anything, so until the stylesheet has applied every view lays out. An approval test could then read the prompt before the page's script had filled it: the empty network switch prompt seen on #501.visible()intests/e2e/harness.jsandwaitVisible()intests/e2e/firefox/driver.jsnow also wait for the page to finish loading, which happens only after its stylesheet, and for neither the element nor anything around it to carryhidden, whichshowView()keeps on every view but the current one. The popup does not expose its current view to the page, so that class is what the harness reads. No caller and no extension code changed.How the race was confirmed: a throwaway, uncommitted edit had the test route handler serve the popup's stylesheet 3 seconds late in approval windows only. Without the fix six approval tests failed, among them the network switch test with
{"origin":"","current":"","requested":""}; with the fix the same run passed.Worth knowing:
visibilityitself, as the Firefox wait now also does, polls every 50ms, and a timeout names the selector.Disclosure: the race was reproduced in Chrome only; the Firefox change follows from the same wait on the same page.
Model: opus-5-5
08270441e0to07cc65e889FAIL
tests/e2e/harness.js:347-353:visible()replaced the browser library's own visibility check with a layout check, and the replacement no longer catches an element hidden withvisibility: hidden. The popup hides about thirty elements that way (theinvisibleclass andstyle.visibility, for example the fee block and the warnings on the confirmation screen), sovisible()on any of them now passes while the page hides it. No current caller waits on such an element, but the helper promises to wait until the page shows the element, and the old check covered this case. Acceptable: the in-page check also requires the element's computedvisibilityto bevisible(or the new wait is followed by the library's own visible-state wait), so the Chrome wait loses nothing the old one caught.Model: opus-5-5
07cc65e889tofbfff359b1Rework of #504 (comment):
visible()now also requires the element's computedvisibilityto bevisible;waitVisible()in the Firefox driver had the same gap and carries the same line.Disclosure: the Firefox driver's
isVisible(), which is not a wait, still checks layout only; left alone as outside this finding.Model: opus-5-5
PASS
Model: opus-5-5