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
fs-list (@finsweet/attributes-list) — reproduced on 1.14.6 / current master.
Describe the bug
Filter conditions are keyed by field + operator (in src/filter/standard/conditions.ts, id = ${fieldKey}_${op}, and the matching findIndex in src/filter/standard/index.ts). When two radio inputs in the same native radio group target the same field but use different operators, selecting one radio does not clear the other's condition.
A native radio group is mutually exclusive only in the DOM: selecting radio B auto-deselects radio A without firing an input/change event on A, so the form listener never runs for A and A's condition is never cleared. Because A and B resolve to different condition ids (different operator), both conditions stay "live" simultaneously.
With the default conditionsmatch="and", the two leftover conditions get ANDed. If they're semantically exclusive (e.g. == 0 and >= 1), the combination is impossible → 0 results, silently. (Setting conditionsmatch="or" doesn't help — it then matches everything.)
It works fine when every radio in the group shares the same operator, because they all collapse into a single field+op condition that gets overwritten on each selection. The bug only appears once operators differ within one group — which makes it confusing to diagnose, since "the default operator works."
To Reproduce
Steps to reproduce the behavior:
Build a standard fs-list with a numeric field qty. Items expose it as a number, e.g. <div fs-list-field="qty" fs-list-fieldtype="number">0</div>. Have some items with qty = 0 and some with qty >= 1.
Add a filters form with one radio group (same name), all fs-list-field="qty":
Click "Out of stock" → condition qty equal "0" → list filters correctly.
Click "In stock" → expected qty >= 1. The DOM deselects "Out of stock", but the engine now holds bothqty equal "0" AND qty greater-equal "1".
See error: with the default conditionsmatch="and", this is qty == 0 AND qty >= 1 → 0 results.
(Inspecting list.filters.value.groups[0].conditions after step 4 shows both conditions present, the deselected one still carrying its old value.)
Expected behavior
Selecting a radio in a group should supersede the other radios in that same group, regardless of operator — the conditions belonging to the now-deselected radios (same name / same field) should be cleared, so only the selected radio's condition stays active.
Screenshots
N/A.
Affected devices
Not device-specific — reproducible in any modern browser (verified in Chrome). Not a rendering/OS issue.
Links
No public reproduction link available, but the steps above are self-contained and reproduce it from a blank fs-list setup.
Additional context
Root cause appears to be the input handler in src/filter/standard/index.ts (it only replaces a same-field+op condition or pushes a new one — it never removes the condition of a deselected sibling radio), combined with the field+op keying in src/filter/standard/conditions.ts.
Possible fix: when an input belonging to a radio group changes, clear the conditions for the other radios in that same group (by name/field) before applying the selected radio's condition.
Footgun that can mask this: the operator value must be exactly one of the documented strings (e.g. greater-equal); invalid values are silently discarded and fall back to equal.
Related Attributes
fs-list(@finsweet/attributes-list) — reproduced on1.14.6/ currentmaster.Describe the bug
Filter conditions are keyed by
field + operator(insrc/filter/standard/conditions.ts,id = ${fieldKey}_${op}, and the matchingfindIndexinsrc/filter/standard/index.ts). When two radio inputs in the same native radio group target the same field but use different operators, selecting one radio does not clear the other's condition.A native radio group is mutually exclusive only in the DOM: selecting radio B auto-deselects radio A without firing an
input/changeevent on A, so the form listener never runs for A and A's condition is never cleared. Because A and B resolve to different condition ids (different operator), both conditions stay "live" simultaneously.With the default
conditionsmatch="and", the two leftover conditions get ANDed. If they're semantically exclusive (e.g.== 0and>= 1), the combination is impossible → 0 results, silently. (Settingconditionsmatch="or"doesn't help — it then matches everything.)It works fine when every radio in the group shares the same operator, because they all collapse into a single
field+opcondition that gets overwritten on each selection. The bug only appears once operators differ within one group — which makes it confusing to diagnose, since "the default operator works."To Reproduce
Steps to reproduce the behavior:
Build a standard
fs-listwith a numeric fieldqty. Items expose it as a number, e.g.<div fs-list-field="qty" fs-list-fieldtype="number">0</div>. Have some items withqty = 0and some withqty >= 1.Add a filters form with one radio group (same
name), allfs-list-field="qty":Click "Out of stock" → condition
qty equal "0"→ list filters correctly.Click "In stock" → expected
qty >= 1. The DOM deselects "Out of stock", but the engine now holds bothqty equal "0"ANDqty greater-equal "1".See error: with the default
conditionsmatch="and", this isqty == 0 AND qty >= 1→ 0 results.(Inspecting
list.filters.value.groups[0].conditionsafter step 4 shows both conditions present, the deselected one still carrying its old value.)Expected behavior
Selecting a radio in a group should supersede the other radios in that same group, regardless of operator — the conditions belonging to the now-deselected radios (same
name/ same field) should be cleared, so only the selected radio's condition stays active.Screenshots
N/A.
Affected devices
Not device-specific — reproducible in any modern browser (verified in Chrome). Not a rendering/OS issue.
Links
No public reproduction link available, but the steps above are self-contained and reproduce it from a blank
fs-listsetup.Additional context
inputhandler insrc/filter/standard/index.ts(it only replaces a same-field+opcondition or pushes a new one — it never removes the condition of a deselected sibling radio), combined with thefield+opkeying insrc/filter/standard/conditions.ts.name/field) before applying the selected radio's condition.greater-equal); invalid values are silently discarded and fall back toequal.