[BUG]: layout.uirevision doesn't play well with map subplot auto-fit #7907

Activity

1. camdecoster

   added

   bugsomething brokensomething broken

   plotly-internal

   good for agent

   on Jul 15, 2026
2. robertclaus

   added

   P2considered for next cycleconsidered for next cycle

   size: 3

   on Jul 23, 2026
3. CAOShurong commented on Aug 25, 2026

   

   CAOShurong

   on Aug 25, 2026

   Contributor

   More actions

   Root cause: the panned view is recorded, then discarded because the incoming figure has no view to compare against

   Verified against 71a2ff73b (master, post v4.0.0).

   Step 1 — pan persistence works. A mouse pan hits the moveend handler in src/plots/map/map.js (~line 501): Registry.call('_storeDirectGUIEdit', ...) writes map.center / map.zoom into both gd.layout and _preGUI. So far so good — the user edit and its journal entry exist.

   Step 2 — the uirevision gate passes. On Plotly.react(gd, gd.data, {uirevision: 'v1'}):

   • The edit key map.center matches the pattern /^(map\d*)\.(center|zoom|bearing|pitch)/ in layoutUIControlPatterns (src/plot_api/plot_api.js ~line 2318).
   • With no explicit attr, the revision attribute resolves to 'map.uirevision'; the subplot-level default inherits layout.uirevision (src/plots/plots.js ~line 1066), so oldRev === 'v1'.
   • getNewRev('map.uirevision', layout) finds nothing at map.uirevision in the incoming layout (there is no layout.map object at all), walks up, and falls back to container.uirevision === 'v1'.
   • newRev === oldRev → protection engaged.

   Step 3 — the actual failure point. Protection means: restore the stored value only if the incoming figure agrees with it (src/plot_api/plot_api.js ~line 2427):

   if (valsMatch(newVal, preGUIVal)) {
       // restore the pre-GUI value and keep the edit
       continue;
   }

   Here preGUIVal is the panned {lon, lat} / zoom, but newVal — read from the incoming user layout — is undefined, because on the auto-fit path the caller never supplies map.center/map.zoom. valsMatch(undefined, {...}) is false, execution falls through to delete layoutPreGUI[key], and the panned view is dropped. Immediately afterwards, handleDefaults in src/plots/map/layout_defaults.js (~line 55–60) sees no user-supplied center/zoom (so isFitView trivially holds), recomputes _fitBounds, and updateMap calls map.fitBounds(...) — the snap-back you see in the video.

   This also explains the two asymmetries in the report:

   • Explicit center/zoom from the start works: the incoming layout then carries values that match _preGUI (or differ intentionally), so either branch preserves intent.
   • Cartesian works: axes have exactly this "incoming value is absent" case hard-coded as the autorange/range[...] special case (~lines 2433–2452): when the tail is autorange and the incoming axis has none, the stored range is restored anyway. Map view attributes have no equivalent carve-out.

   Fix direction

   Two viable shapes, both small:

   1. Mirror the autorange carve-out in applyUIRevisions: when the matched pattern is a map.* view attribute, the revision is unchanged, and newVal === undefined while the incoming subplot still requests auto-fit (fitbounds !== false), restore the stored value instead of dropping it. This keeps all the logic in one place but touches the generic engine.
   2. Make the map's auto-fit revision-aware: stash the effective uirevision alongside _fitView at save time, and have handleDefaults skip setting _fitBounds when the revision is unchanged and the current view differs from the last computed fit. This contains the change entirely within the map subplot, which arguably matches how fix: Dynamically compute default zoom/center for map traces #7884 framed the deferred integration.

   Option 2 looks lower-risk to me since it can't perturb cartesian/polar/scene behavior, but option 1 is the more principled fix if other subplot types grow auto-fit paths later. Happy to take a run at either if useful.
4. robertclaus commented on Aug 25, 2026

   

   robertclaus

   on Aug 25, 2026

   More actions

   @CAOShurong thank you for the comment!

   FYI your response was flagged as potentially AI generated on our end. If that's the case please make sure to review any AI content before posting it in the future.