This was generated by AI during triage.
Follow-up from #2307, which fixed a linestrip's unrendered closing edge (last point back to first) being treated as a hit target in nearest_edge_index.
The fix is covered by two new unit tests on _shape.nearest_edge_index directly, and the existing polygon parametrization guards against regressing polygon's (legitimately hittable) closing edge. However, there is no test that drives the reported UX bug through the real canvas hover/click-to-add-point pipeline (find_hover_target -> add_point_to_edge) with a 3+ point linestrip:
tests/e2e/canvas_interaction_test.py edge tests (test_add_point_on_edge, test_add_point_via_context_menu_action) only use polygon.- The only linestrip e2e cases use exactly 2 points, where the phantom-edge bug cannot manifest (index-0 and index-1 are the same physical segment).
Follow-up: add a canvas-level (unit or e2e) test that hovers/clicks on the invisible diagonal of a rendered 3-point linestrip and asserts no edge hit / no spurious point insertion. Non-blocking; the underlying math is already covered.
Follow-up from #2307, which fixed a linestrip's unrendered closing edge (last point back to first) being treated as a hit target in
nearest_edge_index.The fix is covered by two new unit tests on
_shape.nearest_edge_indexdirectly, and the existing polygon parametrization guards against regressing polygon's (legitimately hittable) closing edge. However, there is no test that drives the reported UX bug through the real canvas hover/click-to-add-point pipeline (find_hover_target->add_point_to_edge) with a 3+ point linestrip:tests/e2e/canvas_interaction_test.pyedge tests (test_add_point_on_edge,test_add_point_via_context_menu_action) only usepolygon.Follow-up: add a canvas-level (unit or e2e) test that hovers/clicks on the invisible diagonal of a rendered 3-point linestrip and asserts no edge hit / no spurious point insertion. Non-blocking; the underlying math is already covered.