sl-dialog grabs focus from 3rd party element

[trailsnail]

Hi there,

we are triggering a MoxieManager window to manage folders and images for some content.
This layer is opened from a button within the sl-dialog.

Now it happen, that the sl-dialog from where the MoxieManager is opened, grabs the focus. If we type one charachter (keydown), the focus from filter field is lost. We must click again in this field to type the next character.

Is there a possibility to prevent this behavior? Or is this this a problem caused by bad design on my side? 😆

used debugger; on focusin event on sl-dialog - see it does checkFocus	dom: both elements are separated

Using Shoelace beta.79

Purely from the context, maybe the check of the dialog this.isActive() should return false, if none of its elements are focused?

[claviska]

When a modal-capable component such as <sl-dialog> or <sl-drawer> is activated, a focus trap is used to ensure focus remains in the component per accessibility guidelines. This is what's "stealing" focus, as the MoxieManager dialog is likely outside of the Shoelace dialog.

While Shoelace's modal utility allows for nested modals by keeping track of which ones are active, it only works for Shoelace modals that use the utility. That means third-party dialogs will be fighting with Shoelace dialogs for focus.

If you can place the MoxieManager dialog inside your Shoelace dialog, that might work. It's not the cleanest solution, but without a modal utility that all dialogs/drawers/etc. can tap into, I'm not sure of another way to work around it.

One option is to allow users to disable the dialog's modal behavior (see #841), but I can't think of a solid use case for contained dialogs outside of making things like this work, and that will lead to problems with accessibility.

[trailsnail]

I understand the problem.
Unfortunately, the MoxieManager does not provide me with the possibility to define a container.
Making adjustments in the minified code of the MoxieManager also goes too far at this point.
Due to the jQuery dependency, it is a candidate to be replaced anyway.
But since that's not happening anytime soon, I'm now at a dead end. Rebuilding our CMS framework to replace the sl-dialog to use the MoxieManager is out of the question.
Is there no option to set an attribute to the sl-dialog to disable the focus check? Of course, so there is the possibility that this could create new problems, but with an appropriate warning in the documentation to use this attribute with caution?

That would be at least currently a great help.
If there is really nothing to be done, I accept that and hope that our customers still have some patience until we can offer a generally different solution.

[claviska]

Have you considered closing the Shoelace dialog when you launch the other dialog? Then you can reopen it when the other dialog closes. Using the animation registry, you can temporarily remove the animation so it's less distracting. https://shoelace.style/components/dialog?id=animations

[trailsnail]

A very good idea. Unfortunately I already have logic attached to the sl-hide event that represents "I'm done editing", such as clearing the panel or TinyMce destroy.
To show the dialog again after closing or selecting a file, I only have its oninsert hook. But if I overwrite it, the selected file from the MoxieManager is no longer taken over into the input of the dialog. Instead only the dialog is shown again.

I am at the end 🤣 anyway thanks for your ideas