Collpasing an SlDetails within a SlDrawer closes the drawer.

[modmuss50]

Hello!

I am using react to create an SlDrawer that contains a number of SlDetails, following the example code provided in the documentation this works well untill collpasing the details pane. When collpasing the details pane the parent drawer is also closed.

I created a codepen displaying this behaviour here https://codepen.io/modmuss50/pen/LYOOGGL This pen is forked from the code provides on the details docs page.

The expected behaviour would be for the drawer to not close when the details pane is closed. I believe the issue is related to onSlAfterHide removing this clearly prevents the drawer from beign opened again.

Please let me know if you need any more info.

Thanks in advance for the help. 👍

[claviska]

This is almost certainly due to the drawer not checking the event target. (Both components emit the sl-after-hide event.)

I’m converting this to a bug to track. Thanks for reporting it!

[claviska]

See #679

[claviska]

See my comment here for a fix: #679 (comment)

[modmuss50]

That works great, thanks a lot 👍

[tpluscode]

I just happen to observe said behaviour when nesting two sl-details elements. No react, just web components

Are you sure that this is not in fact a bug?

[claviska]

I can't reproduce it in the latest version. https://codepen.io/claviska/pen/GRxjwJq?editors=1000

Can you confirm you're using the latest, as there was a related bug fix in beta.69 so earlier versions may not work the same way.

[tpluscode]

Obviously, this happens in a more complex scenario. Shoelace, being a secondary dependency, was set to ^beta.74. I can try updating but here's what I think is happening.

I have my own listener on sl-hide to track open/hidden state outside of the element itself. When my flick my flag it causes and update which the sets open = false and hence both hide. I shall dig a little deeper I suppose

[tpluscode]

Yes, pretty sure thet it what is happening. Same thing with sl-select inside sl-details now. You can see here

Do see the event target being logged here:

Untitled_.Jul.14.2022.10_16.AM.mp4

I find that the sl-hide even emitted by select is bubbing and composed. Thus, it triggers my own handler on the sl-details as you can see that the target is the select and then the second time it's my closing the details itself as the second event fires.

Before I get into stopping their propagation or guarding in upstream handlers, why are those event dispatched that way? I think this is what this article warns against?

[claviska]

I find that the sl-hide even emitted by select is bubbing and composed. Thus, it triggers my own handler on the sl-details as you can see that the target is the select and then the second time it's my closing the details itself as the second event fires.

This is intentional, and very similar to how other events such as click works. (A click inside a parent element will bubble up through its ancestors.) The solution is to check event.target to make sure the event originates from the correct source before responding to it.