ScaleBox plugin - Custom scales are not reported when opening the map

[ale-cristofori]

Description

If there are custom scales defined in the new.json file when opening a new map the scales are not reported on the ScaleBox plugin.
To make the plugin show the user defined scales, the user has to open the print plugin dialog window. At tha point the scales in the scalebox change and become those user's defined. This is not correct, user defined scales should always be coherent.
In fact when refreshing the map the scales become 'broken' again.

How to reproduce

• In new.json define a list of custom scales, in config.yaml fo the same, defining the same scales, so that the map has the same scales for both the visualization and the prints.
• Create a new map from the home page.

Expected Result
The scalebox plugin should contain the list of the custom scales defined by the user in the new.json file.

Current Result
The scalebox plugin does not contain the list of the custom scales defined by the user in the new.json file but the default ones. To make the scalebox show the custom scales the user has to open the print plugin dialog window. More over if the user saves the map the custom scales are not recorded and the newly saved map when opened represents the same buggy behaviour.

• Not browser related

Browser info

(use this site: https://www.whatsmybrowser.org/ for non expert users)

Browser Affected	Version
Internet Explorer
Edge
Chrome
Firefox
Safari

Other useful information

recording_1.mp4

[dsuren1]

@tdipisa

Investigation

When custom scales are defined in new.json via mapOptions.view.scales, the ScaleBox plugin does not display them on initial map load. Instead, it shows the default zoom ladder. Opening the Print plugin dialog causes the scales to "fix themselves" temporarily, because the print flow triggers resolution hooks that recalculate scales. On page refresh, the ScaleBox reverts to the default scales.

Note

It works fine when configured via mapOptions.view.resolutions

Root Cause

The ScaleBox plugin selector computed scales exclusively via getScales, which derives scales from getResolutions(). This function uses a RESOLUTIONS_HOOK if registered, otherwise falls back to the default resolution ladder (zoom 0–21).

Fix

Introduce a custom helper in the plugin selector to validate the map configuration before falling back to default values. The fix should be relatively straightforward

Priority rules

Config in mapOptions.view	ScaleBox shows
scales only	Configured scales directly
resolutions only	Scales computed from resolutions via getScale()
Both scales and resolutions	Configured scales (scales win)
Neither	Default scales from getScales()

This mirrors the priority documented in withScalesDenominators

[tdipisa]

Thank you @dsuren1. Just a question: is this a bug/regression or is there a reason why the the tool is behaving like that? I would like to be sure to not break behaviors introduced recently for specific reasons. What functional tests are saying about that? Can you please double check and maybe have a quick sync with @offtherailz about that?

[dsuren1]

@tdipisa
To be precise, this is not a regression but rather an overlooked scenario. It works as expected when only resolutions are configured in new.json via mapOptions.view.resolutions, since the Map’s RESOLUTIONS_HOOK exposes those resolutions globally and the selector re-evaluates after the first zoom change.

However, when configured using mapOptions.view.scales, the behavior breaks. This is because withScalesDenominators is a component-level transform that does not persist values back to the global state. As a result, there is nothing for the hook to consume unless a change scale action is dispatched, which updates both scales and resolutions in the state

[ale-cristofori]

@dsuren1 @tdipisa we can proceed with the fix.