PR State:
merged
PR:
#1281
Commit:
97867a977fe4f46dbd1141c29678515748dc5571
[FIX] project: wait for quick-create to enable before editing
The "Second task" step in project_update_tour ran right after the
prior quick-create ("New task") was validated, while
KanbanRecordQuickCreate was still in its post-validate disabled
window (o_disabled, pointer-events: none) held until web_save ->
web_read -> onchange -> model.load resolve. Under network/CI latency
the tour's click, aimed at that inert input, resolved to the ancestor
`.o_kanban_group` instead (pointer-events: none excludes the input
from hit-testing), and the following edit step then failed with
"target should be editable".
This reproduced 3/3 on retry within a single Viindoo runbot build
but was intermittent across separate builds, consistent with a
latency-dependent race, and reproduced locally on demand by
injecting 150ms of CDP network latency.
Guard the step's trigger to wait until the quick-create leaves
o_disabled before interacting. The earlier "New task" edit step is
left unchanged: it runs right after opening a fresh quick-create,
not inside any post-validate disabled window.
Verified on this fix: one 0ms-latency run and two 150ms-latency runs,
two tours succeeded and none failed in each run. Without the guard
the same 150ms latency fails the tour at this step. Live users are
unaffected: focus stays in the quick-create input during the save.
Forward-port to 19.0: applied unchanged. KanbanRecordQuickCreate on
19.0 keeps the same disabled window between the previous record's
save and model.load, so the guard addresses the same race.
Re-verified on 19.0 (fresh project database, no demo data, same
Chrome build): both tours of test_01_project_tour succeeded, 0 failed
of 1 test.
X-original-commit: ffcd4ae4ee8b3ce5bef087f5f049c96f62f37e87
Signed-off-by: David Tran <david.tran@tvtmarine.com>
Branch:
19.0