randy
d9879bad60
If Locate was already tracking via the browser-geolocation fallback (GNSS was off when clicked) and GNSS then gets turned on via the sidebar, it kept using the browser position until the button was clicked again -- the browser's own (often less accurate) position had no business still being used once the app's own receiver had a fix. GnssControl#onEnabledChange (a small internal callback list) notifies LocateControl the moment the sidebar toggle changes; if it's actively tracking via the browser at that point, it stops that and jumps to GNSS's position instead. Caught a real bug while verifying this: the automatic handoff reused the same jump-to-GNSS helper a deliberate click uses, which alerts if GNSS has no fix yet -- but GNSS only just turned on and almost certainly hasn't gotten its first poll response back yet at the exact moment the handoff fires, so this popped a blocking window.alert() (which halts the whole page until dismissed) on every single enable. A test hung on exactly this before I noticed. Fixed with an alertIfNoFix option, true only for the deliberate-click path. Verified end to end (simulating the "already tracking" state directly since headless geolocation isn't reliable enough to trust as the trigger): toggling GNSS mid-track removes the blue browser marker, shows the green GNSS one once its poll lands, and no dialog appears.