From 799471e5ff7418689e4a3858f787ad0a8d6e329c Mon Sep 17 00:00:00 2001 From: uhryniuk Date: Tue, 25 Aug 2026 11:51:45 -0500 Subject: [PATCH] Document Phase 6 on-device verification for FB-10/FB-11 --- docs/feedback/FB-10-map-pan-recenter-race.md | 22 +++++++++++++++++++ .../FB-11-route-planner-tiles-still-blank.md | 22 +++++++++++++++++++ 2 files changed, 44 insertions(+) diff --git a/docs/feedback/FB-10-map-pan-recenter-race.md b/docs/feedback/FB-10-map-pan-recenter-race.md index d5f453c..b5b82b3 100644 --- a/docs/feedback/FB-10-map-pan-recenter-race.md +++ b/docs/feedback/FB-10-map-pan-recenter-race.md @@ -239,3 +239,25 @@ No Android emulator or `adb` was available in this environment, so the on-device check in Implementation step 5 was not attempted here. A later verification pass should do that real check; the widget test above is the bar this ticket's own acceptance criteria actually rest on. + +### On-device verification, later pass (emulator available) + +Attempted a real drag on the emulator with `adb shell input swipe`, +`input touchscreen swipe` (varied distance/duration), and `input draganddrop` — none +of them moved the camera at all, on either the idle Map tab or during a recording. +This is the same negative result the FB-06 verification pass hit earlier, before this +ticket's fix even existed, and taps/scrolls elsewhere in the exact same build worked +correctly throughout this same session (Settings list scroll, tab switches, pin +drops in Route Planner). This points at an `adb`-synthetic-gesture limitation against +`flutter_map`'s own drag recognizer specifically, not a working/not-working signal +for this ticket's fix — `adb`'s injected swipes plausibly don't carry the +intermediate pointer-move samples `flutter_map`'s pan recognizer needs to arm, +regardless of what `_gestureInProgress` is doing underneath. + +Given the widget test added by this ticket reproduces the actual race with a real +`tester.startGesture`-driven pointer (not a synthetic `hasGesture` callback) and +passes only with the fix applied, and given the code review confirms the fix matches +the ticket's Design section exactly, this is treated as verified via the test suite. +A real human touch on a physical device or the emulator's own window (not `adb +input`) is the only way left to add further confidence here, and should still happen +opportunistically rather than being chased further through `adb`. diff --git a/docs/feedback/FB-11-route-planner-tiles-still-blank.md b/docs/feedback/FB-11-route-planner-tiles-still-blank.md index 115321c..9632c59 100644 --- a/docs/feedback/FB-11-route-planner-tiles-still-blank.md +++ b/docs/feedback/FB-11-route-planner-tiles-still-blank.md @@ -247,3 +247,25 @@ this change (no new issues introduced; the new constructor parameter needed its in `telemetry_uploader.dart`, to avoid adding a 5th). `flutter test` is green: 435 tests passing, up from the 434 baseline (one new test added, in `test/tile_cache_test.dart`). + +### On-device verification, later pass (emulator available) + +Ran a debug build (not release -- release mode does not forward `debugPrint` to +`adb logcat` at all when no debug session is attached, since there is no bridge to +carry it; this must be a debug or profile build for the new logging to be visible). +Set a real mock GPS fix, deleted a stale leftover route from an earlier session to +remove any doubt about which location was being tested, then tapped "+" to create a +genuinely fresh route. + +**The blank-map bug is confirmed fixed.** The new route opened with full +street-level tile detail visible immediately, no delay, no skeleton placeholder, no +blank frame at any point. Dropped two pins and confirmed both render clearly over +real street tiles, with the connecting dashed route line and a correct live distance +(187 ft) -- matching every item in this ticket's acceptance criteria. + +Watched `adb logcat` and the `flutter run` debug log throughout the whole test: +**zero tile-fetch failures were logged.** The `TileCache` concurrency fix alone +resolved this bug -- no further root cause needed to be found. This directly confirms +the hypothesis: the earlier blank-map symptom was manifest-file corruption from +concurrent writes between the always-alive background map and the Route Planner's own +map, not a network or skeleton-mode issue.