dragbox: sync ax._input.range during pan and scroll-zoom#2
Draft
robertcollar-kobold wants to merge 1 commit into
Draft
dragbox: sync ax._input.range during pan and scroll-zoom#2robertcollar-kobold wants to merge 1 commit into
robertcollar-kobold wants to merge 1 commit into
Conversation
…croll-zoom scaleZoom() consistently writes both `ax.range` and `ax._input.range` (scale_zoom.js:13), but several mutation sites in dragbox.js only wrote `ax.range`: * zoomWheelOneAxis (mousewheel zoom) * dz (corner-handle zoom on drag) * updateMatchedAxRange (linked-axis update during drag) * dragAxList (pan) `ax._input.range` is what `gd.layout.<axis>.range` references. Leaving it stale means user code reading `gd.layout` from a `plotly_relayouting` handler sees the *previous* range while `gd._fullLayout` already reflects the in-progress gesture. Any work that handler does (recomputing positions, fetching new tiles, updating annotations) is therefore computed against an out-of-date viewport, and only "catches up" once dragTail eventually runs a full relayout. This is reproducible by attaching a relayouting handler that compares gd.layout.xaxis.range to gd._fullLayout.xaxis.range during a wheel zoom - before the fix the two diverge; after the fix they stay in sync. The change is the minimal extension of the existing `ax.range = …` assignments to also set `ax._input.range`, matching the pattern already used by scaleZoom and Plotly.relayout.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
scaleZoomandPlotly.relayoutboth maintain the invariant thatax.rangeandax._input.rangestay in sync. Several mutation sites indragbox.jsviolate it, only writingax.range:zoomWheelOneAxis(mousewheel zoom)dz(corner-handle zoom on drag)updateMatchedAxRange(linked-axis update during drag)dragAxList(pan)ax._input.rangeis whatgd.layout.<axis>.rangereferences. Leaving it stale means user code readinggd.layout.<axis>.rangefrom aplotly_relayoutinghandler sees the previous range whilegd._fullLayoutalready reflects the in-progress gesture. Anything that handler does (recomputing positions, fetching tiles, updating annotations) is computed against an out-of-date viewport, and only catches up oncedragTailruns the eventual full relayout.The fix is the minimal extension of the existing assignments to also write
ax._input.range, matching the pattern already used byscaleZoomand the relayout path inplot_api.js.How the bug manifests
Concrete repro: a tile-pyramid demo using a
plotly_relayoutinghandler that readsgd.layout.xaxis.rangeto decide which OSM tiles to fetch on each frame of a wheel-zoom gesture. Across a tile-pyramid level boundary the handler computed tiles for the old range, so when the new tiles loaded they were rendered at coordinates that didn't match the actual viewport — geographic features visibly jumped.A minimal in-page check before/after:
Before the fix:
layoutreports[0.4, 0.6],fullLayoutreports[0.4095, 0.5905].After the fix: both report
[0.4095, 0.5905].Test plan
npm run test-jasmine -- cartesian_interact --nowatch --Chromenpm run test-jasmine -- axes --nowatch --Chromeplotly_relayoutinghandler logging bothgd.layoutandgd._fullLayoutranges; pan and wheel-zoom and verify they agree