Adapters: stop reporting a finished drawing's clicks as map clicks
Motivation
Finishing a drawn shape makes the map report clicks the user never aimed at it. Both engines deliver the finishing gesture's clicks after the drawing session has already ended — one engine delivers the native click that trails the committing gesture (two of them on a double-click finish), the other deliberately holds every click for a beat to rule out a double-click, so the final vertex's click can land after Enter has ended the session. By then the "am I drawing?" check says no, and the click is reported as an ordinary map click. Consequences today: finishing a drawing silently deselects the user's active feature, and anything a plugin opens in response to a finished drawing is dismissed by a click that never happened.
How it should work
Clicks that belong to a drawing gesture are never reported as map clicks — on either engine, however the session ends (single click, double-click, Enter, or programmatically). The very next click the user genuinely makes after finishing is reported normally. A double-click finish does not zoom the map. Nothing changes for consumers of map clicks except that the phantom reports disappear.
Done when
Out of scope
Draft implementation plan — written as of 8a0ed08 on 2026-08-27. Rough guide; re-verify against latest code.
Current behavior
The fix already exists on feature/298-map-popup-service (PR #303), interleaved with the popup service; this issue extracts it into its own PR beneath #303. The pieces: DrawPointerWatch and DrawEndClickGuard in src/essence/Basics/MapEngines/Adapters/DrawingHelpers.ts (time-based absorption keyed to hammer's 300ms tap interval); LeafletAdapter funnels all click subscribers through one adapter-owned map listener where the drawing session and the guard are checked once; DeckGLAdapter extracts _onPointerClick/_onPointerHover with the same guard check; both adapters arm the guard in finishDrawing/disableDrawing and dispose it in destroy; Map_.js's feature-deselect handler moves onto the engine click path (plus an L.point coercion for the engine's plain {x,y} layer point).
Where the change lands & rough plan
Build the new branch from development by copying the drawing-click subset out of the 298 tip (adapters get the click machinery but NOT the deck.gl camera-event work — move emission, bearing/pitch sync — which is popup anchoring and stays in #303). Partition the test files the same way. Then merge the new branch into feature/298-map-popup-service (content is a subset of 298's, so the merge is a no-op on 298's side) and retarget PR #303's base onto the new branch.
⚠️ Gotcha: gh pr edit fails on this repo — retarget the PR base with a REST PATCH (gh api -X PATCH repos/NASA-IMPACT/MMGIS/pulls/303 -f base=...).
Adapters: stop reporting a finished drawing's clicks as map clicks
Motivation
Finishing a drawn shape makes the map report clicks the user never aimed at it. Both engines deliver the finishing gesture's clicks after the drawing session has already ended — one engine delivers the native click that trails the committing gesture (two of them on a double-click finish), the other deliberately holds every click for a beat to rule out a double-click, so the final vertex's click can land after Enter has ended the session. By then the "am I drawing?" check says no, and the click is reported as an ordinary map click. Consequences today: finishing a drawing silently deselects the user's active feature, and anything a plugin opens in response to a finished drawing is dismissed by a click that never happened.
How it should work
Clicks that belong to a drawing gesture are never reported as map clicks — on either engine, however the session ends (single click, double-click, Enter, or programmatically). The very next click the user genuinely makes after finishing is reported normally. A double-click finish does not zoom the map. Nothing changes for consumers of map clicks except that the phantom reports disappear.
Done when
Out of scope
Draft implementation plan — written as of 8a0ed08 on 2026-08-27. Rough guide; re-verify against latest code.
Current behavior
The fix already exists on
feature/298-map-popup-service(PR #303), interleaved with the popup service; this issue extracts it into its own PR beneath #303. The pieces:DrawPointerWatchandDrawEndClickGuardinsrc/essence/Basics/MapEngines/Adapters/DrawingHelpers.ts(time-based absorption keyed to hammer's 300ms tap interval); LeafletAdapter funnels all click subscribers through one adapter-owned map listener where the drawing session and the guard are checked once; DeckGLAdapter extracts_onPointerClick/_onPointerHoverwith the same guard check; both adapters arm the guard infinishDrawing/disableDrawingand dispose it indestroy;Map_.js's feature-deselect handler moves onto the engine click path (plus anL.pointcoercion for the engine's plain{x,y}layer point).Where the change lands & rough plan
Build the new branch from
developmentby copying the drawing-click subset out of the 298 tip (adapters get the click machinery but NOT the deck.gl camera-event work —moveemission, bearing/pitch sync — which is popup anchoring and stays in #303). Partition the test files the same way. Then merge the new branch intofeature/298-map-popup-service(content is a subset of 298's, so the merge is a no-op on 298's side) and retarget PR #303's base onto the new branch.