Description
As soon as any spec override captures a setting, the real preview stops following edits made to that setting on the general settings page. The preview keeps rendering the value that was last banked into the override store, so a boolean usually shows as off no matter what is configured. The live frames are correct the whole time, only the preview is wrong.
Found on the raid frame health bar booleans (Vertical Health Bars), but the resolver is shared, so every module with a real preview is affected.
Steps to reproduce
- Raid Frames > Health Bar: enable Vertical Health Bars.
- Set Preview Mode to Real.
- Create a spec override for a different spec and change Vertical Health Bars there.
- Go back to the general settings page.
- Toggle Vertical Health Bars.
Expected
The preview follows the toggle. If the current spec's override owns the value, the preview keeps showing the override's value instead, with the gold Preview Mode chrome saying so.
Actual
The preview is pinned to the value stored in the override's default map and never moves, whatever is configured on the page. It only catches up after the next harvest (view exit, spec change, logout).
Cause
SpecOverrides_PeekEffectiveValues resolves every fkey in an entry's default map, falling back to the stored default when the current spec's own map does not carry the key. _RebuildPvOverlay copies that map into _pvOverlayProxy, which wins over db.profile for every preview read. But the overlay is only ever built while the Default view is open (SpecOverrides_ViewActive returns false for editing-as and conditional sessions) and that view is exactly the state that holds the default values live for editing. The stored copy therefore shadows the values being edited.
The same resolver also decodes NIL_SENT on defaults-backed keys, which the writers refuse as harvest residue via HasRegisteredDefault. That hands the preview a nil the live frames never hold, and a nil boolean reads as off.
Version
EllesmereUI: 9.1.8
WoW Client: 12.1.0.69587
Description
As soon as any spec override captures a setting, the real preview stops following edits made to that setting on the general settings page. The preview keeps rendering the value that was last banked into the override store, so a boolean usually shows as off no matter what is configured. The live frames are correct the whole time, only the preview is wrong.
Found on the raid frame health bar booleans (Vertical Health Bars), but the resolver is shared, so every module with a real preview is affected.
Steps to reproduce
Expected
The preview follows the toggle. If the current spec's override owns the value, the preview keeps showing the override's value instead, with the gold Preview Mode chrome saying so.
Actual
The preview is pinned to the value stored in the override's default map and never moves, whatever is configured on the page. It only catches up after the next harvest (view exit, spec change, logout).
Cause
SpecOverrides_PeekEffectiveValuesresolves every fkey in an entry's default map, falling back to the stored default when the current spec's own map does not carry the key._RebuildPvOverlaycopies that map into_pvOverlayProxy, which wins overdb.profilefor every preview read. But the overlay is only ever built while the Default view is open (SpecOverrides_ViewActivereturns false for editing-as and conditional sessions) and that view is exactly the state that holds the default values live for editing. The stored copy therefore shadows the values being edited.The same resolver also decodes NIL_SENT on defaults-backed keys, which the writers refuse as harvest residue via
HasRegisteredDefault. That hands the preview a nil the live frames never hold, and a nil boolean reads as off.Version
EllesmereUI: 9.1.8
WoW Client: 12.1.0.69587