HSF / phoenix / 34966602850

50%

master: 38%

push

github

fix(event-display): keep a cut's default range over clone and save/load (#1037)

A Cut captures the bounds it is constructed with as the values `reset()`
restores. Both `clone()` and `fromJSON()` rebuild a Cut through that same
constructor using its *current* bounds, so any narrowing the user has applied
silently becomes the new default.

For `fromJSON` this sits on the state-restore path: `restoreCutsFromJSON`
rebuilds every cut that way and hands the result to the menu, which is what the
"Reset cuts" button operates on. So after saving a state with pT narrowed to
40-60 and loading it back, "Reset cuts" returns to 40-60 rather than the
collection's configured 0-100, and the full range cannot be recovered without
reloading the event. Widening back out after narrowing in is the point of the
button, and since the value shown is the one the user saved, it reads as the
button being dead rather than the range having been lost.

`CutJSON` had nowhere to carry the defaults, so add an optional `defaults`
block and populate it in `toJSON`. `fromJSON` constructs from those defaults
and then applies the saved active values on top. The field is optional and
falls back to the active values, so state files written before this change
still load with exactly today's behaviour.

`clone()` gets the same treatment, building from the source's defaults rather
than its current values. It is called once per collection at load time from
pristine cuts, so it does not misbehave today, but it is the same defect.

Added tests for reset-after-clone, reset-after-round-trip, and the legacy
no-defaults fallback. The first three fail before this change. Updated the
existing exact-shape toJSON assertion for the new field; the neighbouring test
asserting no private `defaultMinValue` / `defaultMaxValue` keys leak still
holds, since the defaults are nested under their own key.

Fixes #1036

885 of 2131 branches covered (41.53%)

Branch coverage included in aggregate %.

13 of 13 new or added lines in 1 file covered. (100.0%)

3337 of 6503 relevant lines covered (51.31%)

203.87 hits per line