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

@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.

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

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.

Thanks for the detailed verification and suggestions.

I incorporated the proposed changes in 0475c41:

• Re-mounted the canonical colorbar attributes after overrideAll.
• Moved the invariant test into the existing colorbar_test.js suite.
• Merged the latest upstream/main.
• Removed scattermapbox coverage because main no longer contains that trace.
• Regenerated test/plot-schema.json.

I kept the scatter3d case out of this PR to keep the scope focused. It can be addressed in a follow-up.

I will also describe this PR as a schema and update-path fix. The current evidence does not prove that the edit type caused the initial-render timing reported in #7869.

The schema drift check, lint, typecheck, and syntax tests pass locally.