Commit d606dd5
fix(dashboard): getTimeRange returns full data extent under an active TimeWindow (#284)
FastSenseWidget.getTimeRange() reports the cached data extent for the navigator/preview, which must be independent of the per-widget TimeWindow_. But updateTimeRangeCache()'s fast path trusted the already-pulled x as the full extent — and when a TimeWindow_ is set, callers pass the WINDOWED pull (pullData_ -> Tag.getXYRange). That set CachedXMax to the window end, so getTimeRange() returned [fullStart, windowEnd] (CachedXMin is sticky, which is why only the max was wrong).
Fix: only take the passed-x fast path when TimeWindow_ is empty; with a window active, fall through to the Tag's own (full) getTimeRange()/getXY(). No extra work in the common windowless case; one O(1) Tag.getTimeRange() when windowed.
Regression guard: existing tests/test_dashboard_time_window.m testPreviewStillFull (was failing on main). Verified fresh-process: repro fixed (tMax full extent), test_dashboard_time_window 8/8, and 95/96 across FastSenseWidget/preview/dashboard suites (the 1 is the pre-existing headless TestDashboardEngine/testTimerContinuesAfterError, unrelated).
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>1 parent 9fdc13d commit d606dd5
1 file changed
Lines changed: 7 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1775 | 1775 | | |
1776 | 1776 | | |
1777 | 1777 | | |
1778 | | - | |
| 1778 | + | |
1779 | 1779 | | |
| 1780 | + | |
| 1781 | + | |
| 1782 | + | |
| 1783 | + | |
| 1784 | + | |
| 1785 | + | |
1780 | 1786 | | |
1781 | 1787 | | |
1782 | 1788 | | |
| |||
0 commit comments