Closed NickantX closed 2 years ago
Found out it was caused by keeping the class smui-accordion__panel--opened
after opening the panel and closing it too quickly.
Looking at the generated css, I found this :
.smui-accordion__panel.smui-accordion__panel--opened>.smui-paper__content{overflow:visible}
This therefore adds overflow: visible
to the content because the class smui-accordion__panel--opened
is kept, even when the panel is closed.
A quick workaround until a fix for smui-accordion__panel--opened
is made is to add the style overflow: hidden
to the panel based on the condition that it is opened or not ;
<Panel class={open ? '' : 'overflow-hidden'} [...]>
[...]
Note : I'm using Windicss / TailwindCss so adding a class is faster for me, but it would be the same as adding style={open ? '' : 'overflow: hidden;'}
to the Panel component.
Edit : I tested it in an accordion that doesn't bug (trying accordions in accordions currently doesn't work well), and the workaround above actually makes the animation a bit janky - YMMV!
Edit 2 : Adding this (you can scope it if desired, I'm simply applying it globally currently) fixes partially the issue :
<style>
:global(.smui-accordion__panel.smui-accordion__panel--opened:not(.smui-accordion__panel--open)) {
overflow: hidden;
}
</style>
This hides the "opened" state, but it does show in full again during the opening animation - currently trying to figure out a way to hide the overflow until the animation ends!
This is one of the best, most detailed bug reports I've ever gotten. And thank you, @V-ed for the fix! This is awesome!
Describe the bug Closed Accordion content remains somewhat visible if it is closed too quickly, and another accordion is opened.
To Reproduce Steps to reproduce the behavior:
Expected behavior The first accordion remains closed, just like if it was opened and closed slower
Screenshots GIF More panels
Desktop (please complete the following information):
Additional context This issue can be seen on the SMUI docs page for Accordions.