fix: correct colorbar editType for map traces (issue #5616 in ploty.py)

[yqtian-se]

Fix colorbar editType for map traces (Issue #5616)

Overview

This PR fixes a bug where setting marker.colorbar properties (e.g., tickfont.textcase='normal') during scattermap/scattergeo/scattermapbox initialization would cause the map to blank on the initial render.

Related Issue: Fixes #5616 in plotly.py

Root Cause

The three map trace types (scattermap, scattergeo, scattermapbox) had all marker.colorbar properties incorrectly configured with editType='calc' instead of editType='colorbars'.

When a property has editType='calc', it triggers a full plot recalculation. For map traces, this recalculation during initial render was causing the map rendering to fail, leaving only the colorbar visible.

In contrast, non-map traces like scatter use editType='colorbars' for colorbar properties, which only redraws the colorbar without recalculating the entire plot. This is the correct behavior for both map and non-map traces.

Solution

• Added a restoreColorbarEditTypes() helper function to each map trace type's attributes.js
• This function recursively restores editType='colorbars' for all colorbar-related properties after the overrideAll() call
• The function handles nested properties (tickfont, title, etc.) and array items (tickformatstops)
• Regenerated test/plot-schema.json to reflect the corrected editTypes

Files Changed

• src/traces/scattermap/attributes.js
• src/traces/scattergeo/attributes.js
• src/traces/scattermapbox/attributes.js
• test/plot-schema.json
• draftlogs/5616_fix.md

Testing

• Created Python test suite verifying colorbar properties work correctly for scattermap
• All textcase values ('normal', 'upper', 'lower', 'word caps') tested and working
• Verified consistency between scatter and scattermap colorbar behavior

Backward Compatibility

✓ This is a bug fix with no breaking changes
✓ Existing valid figures continue to work
✓ Previously broken figures (blanking maps) now work correctly

Features, Bug fixes, and others:

Before opening a pull request, developer should:

1. make sure they are not on the master branch of their fork as using master for a pull request would make it difficult to fetch upstream changes.
2. fetch latest changes from upstream/master into your fork i.e. origin/master then pull origin/master from you local master.
3. then git rebase master their local dev branch off the latest master which should be sync with upstream/master at this time.
4. make sure to not git add the dist/ folder (the dist/ is updated only on version bumps).
5. make sure to commit changes to the package-lock.json file (if any new dependency required).
6. provide a title and write an overview of what the PR attempts to do with a link to the issue they are trying to address.
7. select the Allow edits from maintainers option (see this article for more details).

After opening a pull request, developer:

• should create a new small markdown log file using the PR number e.g. 1010_fix.md or 1010_add.md inside draftlogs folder as described in this README, commit it and push. A CI check enforces this; PRs that don't warrant a CHANGELOG entry can opt out by applying the no-draftlog label.
• should not force push (i.e. git push -f) to remote branches associated with opened pull requests. Force pushes make it hard for maintainers to keep track of updates. Therefore, if required, please fetch upstream/master and "merge" with master instead of "rebase".

[camdecoster]

Thanks for the PR! Our team will take a look and follow up with you.

[emilykl]

@yqtian-se Thanks for the PR! I haven't yet been able to reproduce the linked issue (see my comment here) so I'm not able to test this PR until I can reproduce.

If you're able to create a Codepen which demonstrates the issue, that would be super helpful. You can also use the live link to this PR build (https://plotly.github.io/plotly.js-dev-builds/upload/pr-7684/latest/plotly.min.js) to demonstrate this fix.