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.

[robertclaus]

@yqtian-se just following up in case you have a chance to create the reproduction @emilykl asked about. Thanks!

[CAOShurong]

Exact-head verification of the schema-level fix (head b4dc27ac)

I verified this PR's attribute-module changes at the exact head commit, and they do what the description says. I also traced what I believe is the actual root cause — which may remove the blocker @emilykl hit (not being able to reproduce the visual symptom).

What I verified at head b4dc27ac

Requiring the three attribute modules directly from the PR head in Node:

• All 72 editable attributes under marker.colorbar in each of scattergeo, scattermap, and scattermapbox now carry editType: 'colorbars' (0 remaining 'calc'), exactly matching the canonical declarations in src/components/colorbar/attributes.js.
• Non-colorbar attributes are untouched: e.g. lon and textposition still declare editType: 'calc' at the PR head.
• Baseline on current main: all 72 are 'calc' — confirming both the bug and the completeness of the flip.
• No shared-object mutation leaks: overrideAll returns fresh copies before the helper mutates them, and loading the PR modules does not alter the canonical colorbar component object.

Root cause (why this is correct even without a visual repro)

The 'calc' pollution comes from overrideAll(attrs, 'calc', 'nested') wrapping these three modules. overrideOne() in src/plot_api/edit_types.js recurses into every nested container and rewrites all editTypes — including the borrowed marker.colorbar subtree, whose members otherwise correctly declare 'colorbars'. Compare heatmap, whose root-level colorbar isn't wrapped that way and keeps 'colorbars' throughout.

So regardless of whether the initial-render blanking in plotly.py #5616 (plotly.js #7869) reproduces on demand, the schema inconsistency is objective: today, editing e.g. marker.colorbar.tickfont.size on a map trace triggers a full calc (data recompute), while every other trace type treats colorbar edits as 'colorbars' (redraw colorbars only). That asymmetry is worth fixing on its own.

Suggestions

1. Smaller diff: the ~30-line restoreColorbarEditTypes helper (currently duplicated in 3 files) could be replaced by re-mounting the canonical component after the override, since the canonical module already overrides its whole subtree via overrideAll(…, 'colorbars', 'from-root'):

   var attrs = overrideAll({ /* ... */ }, 'calc', 'nested');
   
   // overrideAll('calc', 'nested') clobbers the borrowed colorbar subtree;
   // restore it from the canonical declaration
   attrs.marker.colorbar = require('../../components/colorbar/attributes');
   
   module.exports = attrs;

   This restores exactly the state the helper produces — one line per file instead of ~100 lines total.

2. Same latent bug in scatter3d: on main, scatter3d.marker.colorbar.tickfont.textcase also carries editType: 'calc' (same overrideAll(…, 'calc', 'nested') pattern). Worth covering here or in a follow-up so behavior stays consistent across traces.

3. Add a schema-invariant jasmine test, so correctness doesn't depend on image mocks or a manual Codepen (which is what currently blocks review):

   ['scattergeo', 'scattermap', 'scattermapbox'].forEach(function(name) {
       var attrs = require('../../src/traces/' + name + '/attributes');
       it(name + ' declares marker.colorbar edits as colorbars, not calc', function() {
           expect(attrs.marker.colorbar.tickfont.textcase.editType).toBe('colorbars');
       });
   });

   (or walk the whole marker.colorbar subtree asserting no 'calc' remains.)

A Codepen demonstrating the original visual symptom may still help reviewers, but the items above make the PR verifiable without it.