ROU-12729: Fix configuration behavior when respectUserPosition is set to false#257
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes an OSMap refresh edge case where enabling only respectUserZoom could inadvertently prevent programmatic center updates, by separating “respect user position” logic from zoom-change state and applying the corrected guard consistently across providers.
Changes:
- Update Leaflet and Google provider
refresh()logic to respect the current center only when the user has panned andrespectUserPositionis enabled. - Simplify the framework abstraction by removing the combined
hasZoomOrPositionChangedgetter and introducing a focusedrespectUserPositionruntime condition. - Add an ADR documenting the problem scenario, decision, and resulting implementation.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/Providers/Maps/Leaflet/OSMap/OSMap.ts | Adjusts refresh center selection to avoid blocking programmatic center updates when only zoom is respected. |
| src/Providers/Maps/Google/OSMap/OSMap.ts | Mirrors the Leaflet fix for Google Maps refresh center selection, with null-safe center retrieval. |
| src/OSFramework/Maps/OSMap/AbstractMap.ts | Removes the combined change-state getter and introduces a position-specific runtime guard. |
| docs/adr/ADR-0004-Fix-RespectUserZoom-Only-Breaking-Map-Center-Refresh.md | Documents the bug, constraints, and the chosen fix approach. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
JoaoFerreira-FrontEnd
previously approved these changes
Apr 21, 2026
e071d65
|
JoaoFerreira-FrontEnd
approved these changes
Apr 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



This PR is for fixing an issue caused by the introduction of a safeguard for respecting the user pan action. This produced incorrect behavior in a specific scenario:
respectUserZoom(position respect is off)._zoomChanged = true.refreshis called.respectUserChangewastrue(zoom flag is on) andhasZoomOrPositionChangedwastrue(zoom changed), the condition evaluated totrue.positionwas overwritten with the current map center instead of the new programmatic value, so the map never re-centred.The root cause is that
hasZoomOrPositionChangedaggregated both_zoomChangedand_positionChangedinto a single boolean, conflating two independent concerns. A zoom change alone was enough to prevent a programmatic position update from taking effect, even whenrespectUserPositionwas disabled.Test Steps
truePreviously erroneous result: The map center doesn't change, and the zoom changed by the user is kept.
Expected result: The map gets centered in the marker, and the zoom changed by the user is kept.
Checklist