Summary
Opening the modifier panel for a condition causes the panel to compete for space with the condition controls on the same flex line.
The value field collapses to almost no width, while the add-OR, modifier, and remove actions become visually detached from the condition they operate on. The modifier chips appear beside the controls instead of below them.
Environment
- Observed with the Spanish locale
- FHIR R4
- SQLite
- Reproduced on a desktop viewport wider than 900 CSS pixels
- Originally observed on commit
3b46edc07b343ff9ea97a694e80147439e89e0ad
- The same layout structure remains present on current
main
The behavior is UI-only and should not depend on the FHIR version or storage backend.
Steps to reproduce
- Open the visual query builder.
- Select
Patient.
- Add a condition using the
name search parameter.
- Enter any value.
- Open the condition's modifier panel using the gear button.
- Inspect the value field, modifier chips, and row actions.
Actual behavior
- The modifier panel is rendered on the same flex line as the condition controls.
- The value field is compressed until it is barely usable.
- The add-OR button is displaced and appears detached from the value it extends.
- The gear and remove actions sit between the compressed condition and the modifier chips.
- The relationship between the condition, its alternatives, its modifiers, and its destructive action becomes unclear.
Expected behavior
The modifier panel should occupy a separate row within the condition and wrap its chips without reducing the usable width of the primary controls.
Opening or closing the panel must not change the alignment or grouping of:
- the search parameter
- the comparator or modifier selector
- the value and its OR alternatives
- the add-OR action
- the modifier toggle
- the condition removal action
Implementation analysis
The modifier panel is appended as a child of .builder-row and uses flex-basis: 100%.
However, ordinary condition rows do not enable flex-wrap at desktop widths. Wrapping is currently enabled only below the 900-pixel breakpoint and for chain or reverse-chain rows. As a result, flex-basis: 100% does not move the panel onto a new line. Instead, the browser shrinks the other flex items to accommodate it.
The layout should give the expanded panel an explicit full-width row without relying on a flex basis inside a non-wrapping container.
Scope
This issue covers the additional displacement and field collapse caused by opening the modifier panel.
Changing the wording, placement, or broader ownership model of the add-OR action is outside this issue unless required to keep the expanded layout stable.
Query serialization and modifier selection behavior are also outside scope.
Regression coverage
Add browser coverage that opens the modifier panel and verifies geometry, not only visibility and chip behavior.
The coverage should include:
- ordinary condition rows at desktop widths above the 900-pixel breakpoint
- the responsive breakpoint and narrower layouts
- string parameters
- token parameters, which expose more modifier chips
- unknown or custom parameters that may expose the complete modifier set
- English, Spanish, and German copy lengths
- conditions with one and multiple OR alternatives
- no overlap or horizontal overflow
- a usable minimum width for the value field
- stable alignment of the gear and remove actions
- modifier chip interaction after the panel reflows
The existing end-to-end test confirms that the panel becomes visible and that selecting a chip updates the query, but it does not assert layout bounds or detect collapsed controls.
Acceptance criteria
- The expanded modifier panel starts on its own row within the condition.
- Modifier chips wrap inside the available content width.
- The value field remains usable when the panel is open.
- Add-OR, modifier, and remove actions retain stable alignment.
- No control overlaps, clips, or escapes the condition container.
- The layout remains stable across supported desktop and responsive widths.
- Existing modifier selection and OR-alternative behavior continue to work.
Evidence
The screenshot shows the value field collapsed between the modifier selector and the add-OR button after the modifier panel is opened.

Summary
Opening the modifier panel for a condition causes the panel to compete for space with the condition controls on the same flex line.
The value field collapses to almost no width, while the add-OR, modifier, and remove actions become visually detached from the condition they operate on. The modifier chips appear beside the controls instead of below them.
Environment
3b46edc07b343ff9ea97a694e80147439e89e0admainThe behavior is UI-only and should not depend on the FHIR version or storage backend.
Steps to reproduce
Patient.namesearch parameter.Actual behavior
Expected behavior
The modifier panel should occupy a separate row within the condition and wrap its chips without reducing the usable width of the primary controls.
Opening or closing the panel must not change the alignment or grouping of:
Implementation analysis
The modifier panel is appended as a child of
.builder-rowand usesflex-basis: 100%.However, ordinary condition rows do not enable
flex-wrapat desktop widths. Wrapping is currently enabled only below the 900-pixel breakpoint and for chain or reverse-chain rows. As a result,flex-basis: 100%does not move the panel onto a new line. Instead, the browser shrinks the other flex items to accommodate it.The layout should give the expanded panel an explicit full-width row without relying on a flex basis inside a non-wrapping container.
Scope
This issue covers the additional displacement and field collapse caused by opening the modifier panel.
Changing the wording, placement, or broader ownership model of the add-OR action is outside this issue unless required to keep the expanded layout stable.
Query serialization and modifier selection behavior are also outside scope.
Regression coverage
Add browser coverage that opens the modifier panel and verifies geometry, not only visibility and chip behavior.
The coverage should include:
The existing end-to-end test confirms that the panel becomes visible and that selecting a chip updates the query, but it does not assert layout bounds or detect collapsed controls.
Acceptance criteria
Evidence
The screenshot shows the value field collapsed between the modifier selector and the add-OR button after the modifier panel is opened.