You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up from PR #658 review (comment #658 (comment)) and the review-panel discussion. Filed separately because it is a pre-existing transient, orthogonal to that comment's fix (which gated the wasted rescan while highlight-tie is unarmed).
Problem
HistogramPane.RefreshTieFilters refreshes _tieHighlightFilters synchronously, but the histogram data (_baseData, including GroupHighlightMasks) is only replaced when a background scan completes. On a disarm transition (highlight-tie was armed, now unarmed - e.g. the user clears the last highlight color, or the eligible filter count crosses 31), StartScan launches a plain (mask-free) scan but does not clear _baseData synchronously. Until that scan publishes:
_baseData.GroupHighlightMasks still holds the armed masks (ordinals into the previous eligible filter list), while
_tieHighlightFilters has already been reassigned to the new (unarmed) filter set.
Any re-render in that window (ResolveGroupHighlight / GroupColorClass, gated on GroupHighlightMasks is not null) maps the stale mask ordinals through the new filter list, so a sub-frame flash of stale / mis-mapped group-highlight styling (and the corresponding ARIA text) can appear before the plain scan settles.
Scope / severity
Transient and self-healing: the in-flight plain scan publishes mask-free data and the glitch clears.
Visual / accessibility only; no data-correctness impact.
Suggested fix
On a disarm transition, synchronously invalidate the tied display data before the async scan - e.g. clear _baseData.GroupHighlightMasks (or suppress the highlight render path) the moment wasArmed && !willArm, rather than waiting for the plain scan to publish.
Suggested test
Publish armed data, stall the disarm plain scan, issue the disarm edit, and assert the render does not surface stale masks (no histogram-cat-hl, no stale ResolveGroupHighlight mapping) before the scan completes.
Context
Follow-up from PR #658 review (comment #658 (comment)) and the review-panel discussion. Filed separately because it is a pre-existing transient, orthogonal to that comment's fix (which gated the wasted rescan while highlight-tie is unarmed).
Problem
HistogramPane.RefreshTieFiltersrefreshes_tieHighlightFilterssynchronously, but the histogram data (_baseData, includingGroupHighlightMasks) is only replaced when a background scan completes. On a disarm transition (highlight-tie was armed, now unarmed - e.g. the user clears the last highlight color, or the eligible filter count crosses 31),StartScanlaunches a plain (mask-free) scan but does not clear_baseDatasynchronously. Until that scan publishes:_baseData.GroupHighlightMasksstill holds the armed masks (ordinals into the previous eligible filter list), while_tieHighlightFiltershas already been reassigned to the new (unarmed) filter set.Any re-render in that window (
ResolveGroupHighlight/GroupColorClass, gated onGroupHighlightMasks is not null) maps the stale mask ordinals through the new filter list, so a sub-frame flash of stale / mis-mapped group-highlight styling (and the corresponding ARIA text) can appear before the plain scan settles.Scope / severity
Suggested fix
On a disarm transition, synchronously invalidate the tied display data before the async scan - e.g. clear
_baseData.GroupHighlightMasks(or suppress the highlight render path) the momentwasArmed && !willArm, rather than waiting for the plain scan to publish.Suggested test
Publish armed data, stall the disarm plain scan, issue the disarm edit, and assert the render does not surface stale masks (no
histogram-cat-hl, no staleResolveGroupHighlightmapping) before the scan completes.