can any of the maintainer please review the fix for the issue please ?

Hello @SharadhNaidu! Thanks for the PR. I'll try to review this, but it might take a bit to get to.

In the meantime, could you provide some examples that this fixes and some testing steps?

Give me some time please , i'll provide you with few examples with before and after , also the testing steps .

here's the repro from the issue , before/after, and how to test.

example (the case from #7844)

Plotly.newPlot('graph', [{
  type: 'scattergeo', mode: 'markers',
  lat: [43.1155, 32.7157], lon: [131.8855, -179]
}], {
  geo: { fitbounds: 'locations', projection: { type: 'equirectangular' } }
});

the two points sit either side of ±180° before, fitbounds measures the longitude span the long way (~311°) and zooms out to almost the whole world , after it uses the compact crossing range (~49°).

before (v3.6.0) points squashed against opposite edges:

after (this PR) compact view across the antimeridian, framed like any other fitbounds map:

for reference, the eastern-most = 179 case already worked and is unchanged:

what changed:
the range still comes from getAutoRange , but when points straddle ±180 it's swapped for the largest gap complement range (per @rl-utility-man's suggestion) . It only ever shrinks the range , skips choropleth/location traces and whole globe data and I pad the compact range with the same margin getAutoRange uses so markers aren't flush with the frame , for ties (e.g. 91°E and 91°W) it just takes the largest gap deterministically , with no atlantic/pacific preference , happy to document that default.

testing

npm run test-jasmine -- geo

• Test geo fitbounds longitude range — unit tests on the helper (straddling, non-straddling, whole-globe, too-few-points).
• Test geo fitbounds with antimeridian-straddling points — renders the -179 case and checks the fitted range + projection rotation, with a 179 control that keeps the naive centring.

Manual: swap -179 for 179 in the snippet — both now give the same compact view.

i'll attach a few more examples and tests .

a couple more for refrence.

here's a cluster rather than just two points , five markers around the dateline , lon = [170, 175, -178, -175, 179]. Same thing: the naive range comes out [-178, 179] (~357deg, so basically the whole world), and it collapses to [170, 185] (~15deg) with the fix.

Plotly.newPlot('graph', [{
  type: 'scattergeo', mode: 'markers',
  lat: [-18, -16, -14, -20, -22], lon: [170, 175, -178, -175, 179]
}], { geo: { fitbounds: 'locations', projection: { type: 'equirectangular' } } });

before , the cluster ends up split across both edges:

After:

on the tests , in case it saves you a read , the unit block (Test geo fitbounds longitude range) just pins down the helper on its own : it only returns the wrapped range when that's actually tighter , otherwise it hands back null and getAutoRange is left alone (normal data, whole globe data, fewer than two points) . it's really there to show it stays out of the way when it shouldn't trigger the other block (Test geo fitbounds with antimeridian-straddling points) does actual Plotly.newPlot renders and checks the range and rotation come out on the crossing view , plus a non-straddling case that's untouched so ordinary maps don't change .

and since the helper's just a plain module you can sanity-check the logic without a render:

TESTS

node -e "console.log(require('./src/plots/geo/get_fitbounds_lon_range')([131.8855, -179]))"

[ 131.8855, 181 ]

node -e "console.log(require('./src/plots/geo/get_fitbounds_lon_range')([170, 175, -178, -175, 179]))"

[ 170, 185 ]

node -e "console.log(require('./src/plots/geo/get_fitbounds_lon_range')([-10, 0, 20]))"
null

I dont why the one CI run failed , its an animation/transition test , I dont think i have touch any path/file which required "test/jasmine/tests/transition_test.js" , dont know why it failed but just in case I rebased , to the recent changes .

@camdecoster the requested reviews are applied , please let me know if any. Also i have an issue please look into it when free (/issues/7835) I am willing to spend more time on it.

The test failures are unrelated to this PR, so I'm going to merge.

Thanks @camdecoster .