Browser tests: the new-tab and drag tests read the page before the browser has finished

tiagoagueda commented

2026-10-04 20:43:12 +00:00

Owner

Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes two jobs at a time, in the order the workflow file lists them, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict.

The new tab (runs 663 and 690)

test_identifier_schemes.py::test_a_click_that_asks_for_a_new_tab_is_left_to_open_the_page Ctrl+clicks the identifier dialog's opener and waits for the tab Chromium opens. In run 690 the tab's address stayed None: its navigation never committed, even with the 30 s and 15 s waits added after 663. The page it opens is trivial on the server (server_views.py:1042-1097), so the test is measuring how Chromium schedules a background tab under load, not what the application does. What the test promises is that a click with Ctrl or Cmd held is left to the browser: a click listener on window can record whether the application prevented the default and then cancel it, so no tab opens and nothing waits on one.

The drag (known flaky under load)

test_board_drag.py:68 drops a card on a column and then waits for networkidle. The drop moves the card in the page at once and submits the form with requestSubmit() (app.js:948-968), a full navigation; networkidle answers for the page that is already idle, so the database is read while the POST may still be in flight. test_board_fold.py:923 does it right with page.expect_navigation(). The same pattern is at test_board_drag.py:111 and behind the four networkidle waits in test_widget_drag.py.

The unsaved-work sleeps

test_unsaved_work.py:170 and :179 sleep 300 ms and 1,500 ms and then read the database. They wait for the page's state instead.

Done when

Each test waits for the thing it reads, and each passes twenty times in a row with the machine loaded.

Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes **two jobs at a time, in the order the workflow file lists them**, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict. ## The new tab (runs 663 and 690) `test_identifier_schemes.py::test_a_click_that_asks_for_a_new_tab_is_left_to_open_the_page` Ctrl+clicks the identifier dialog's opener and waits for the tab Chromium opens. In run 690 the tab's address stayed `None`: its navigation never committed, even with the 30 s and 15 s waits added after 663. The page it opens is trivial on the server (`server_views.py:1042-1097`), so the test is measuring how Chromium schedules a background tab under load, not what the application does. What the test promises is that a click with Ctrl or Cmd held is left to the browser: a click listener on `window` can record whether the application prevented the default and then cancel it, so no tab opens and nothing waits on one. ## The drag (known flaky under load) `test_board_drag.py:68` drops a card on a column and then waits for `networkidle`. The drop moves the card in the page at once and submits the form with `requestSubmit()` (`app.js:948-968`), a full navigation; `networkidle` answers for the page that is already idle, so the database is read while the POST may still be in flight. `test_board_fold.py:923` does it right with `page.expect_navigation()`. The same pattern is at `test_board_drag.py:111` and behind the four `networkidle` waits in `test_widget_drag.py`. ## The unsaved-work sleeps `test_unsaved_work.py:170` and `:179` sleep 300 ms and 1,500 ms and then read the database. They wait for the page's state instead. ## Done when - Each test waits for the thing it reads, and each passes twenty times in a row with the machine loaded.

tiagoagueda added the

bug

label

2026-10-04 20:43:12 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 22:21:24 +00:00

Wait for what each flaky browser test reads, not for the clock

tiagoagueda closed this issue

2026-10-04 22:21:24 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 23:41:37 +00:00

Wait for the company page in the double-click test, and watch the walk