Repository navigation
Description
Accordion groups configured as initially expanded are rendered in the expanded state, but their content is not visible when the Accordion is shown inside a popup.
The header state is correct:
aria-expanded="true"The content also exists and is fully rendered in the DOM, but the content wrapper receives:
style="height: 0px;"This leaves the group visually collapsed even though the Accordion considers it expanded.
Steps to reproduce
- Place an Accordion widget on a popup page.
- Configure one or more groups to be initially expanded.
- Open the popup.
- Observe that the expand/collapse icon indicates an expanded group, but the content is not visible.
- Inspect the DOM.
Example state after opening the popup:
contentHeight: 127
scrollHeight: 127
wrapperHeight: 0
inlineHeight: "0px"
aria-expanded: true
Disabling Animate does not change the behavior.
Expected behavior
An initially expanded Accordion group should render with its content visible when the popup opens.
Actual behavior
The Accordion content is rendered correctly, but the wrapper remains at an inline height of 0px.
Investigation
Accordion 2.3.6 uses a ResizeObserver on the inner content and updates the wrapper height using:
contentWrapperRef.current.style.height =
`${contentRef.current.getBoundingClientRect().height}px`;The problem appears to be a timing issue during popup initialization.
The likely sequence is:
Accordion renders inside popup
→ group state is correctly initialized as expanded
→ ResizeObserver callback runs while popup is still opening / not fully laid out
→ getBoundingClientRect().height returns 0
→ Accordion writes height: 0px to the wrapper
→ popup finishes opening
→ inner content now has its correct height
→ no new content-box resize occurs
→ ResizeObserver does not update the wrapper again
→ height remains 0px
This was confirmed by checking the group after the popup had fully opened:
contentHeight: 127
scrollHeight: 127
wrapperHeight: 0
inlineHeight: "0px"
An actual content-box size change was then forced on the inner content:
const wrapper = document.querySelector(
'#Accordion42AccordionGroup1ContentWrapper'
);
const content = wrapper.querySelector(
'.widget-accordion-group-content'
);
content.style.minHeight =
`${content.getBoundingClientRect().height + 50}px`;After this change, the Accordion's ResizeObserver fired again and correctly updated the wrapper height.
This confirms that the observer itself is working. The issue is that the initial height is measured incorrectly during popup rendering, and the later popup layout change does not trigger another resize event for the observed content.
Suspected root cause
The Accordion uses getBoundingClientRect().height inside a debounced ResizeObserver callback instead of relying on the size reported by the observer itself.
During popup opening, getBoundingClientRect() can temporarily return 0 because of the popup's rendering, visibility, or transform state, even though the content's actual layout size becomes non-zero shortly afterward.
Since the content's CSS content-box size may not change when the popup becomes fully visible, no second ResizeObserver event is generated, leaving the stale 0px inline height in place.
Additional notes
- The issue also occurs with
Animate = No, because theResizeObserverlogic runs independently of the animation setting. - The relevant
ResizeObserverimplementation appears unchanged across Accordion versions 2.3.3 through 2.3.6. - This therefore does not appear to be a regression introduced specifically in version 2.3.6.
Screenshot

Activity
github-actions commentedon Nov 2, 2026
Thanks for the detailed report. I understand that in Accordion 2.3.6, a group set to be initially expanded inside a popup page renders with an inline
height: 0pxon its content wrapper, so the content stays hidden even though the group is marked as expanded. The "Animate" setting does not change this.I checked the code: the wrapper height is set from
getBoundingClientRect().heightinside a debouncedResizeObservercallback, as you describe. To help maintainers reproduce this, we need a few more details:Once we have this, maintainers will review the issue.
Automated triage by Claude. It can be wrong, and a maintainer makes the final decision.