Layout Paragraphs builder doesn't set "_admin_route" context

There's a conceptual problem here:

+      $this->configFactory->get('node.settings') &&
+      $this->configFactory->get('node.settings')->get('use_admin_theme')

This is a setting for nodes that you're reading.

But the routes you're altering are for any entity type that has paragraph fields on it.

I'm not sure how to resolve that -- maybe make it its own setting rather than piggyback off the setting for nodes?

@hudri - Can you provide a little more detail on the actual issue you are experiencing? CRUD actions in LP are called via Ajax requests, and the correct theme should be determined based on ajax_page_state POST data. Are you seeing cases where the incorrect theme is being used? If so, can you provide more detail about the context?

I initially noticed this behavior because drupalSettings.path.currentPathIsAdmin is derived from the _admin_route context. This setting is the proper way for JS behaviors to detect if we are in admin in frontend mode (core does this in toolbar module and in layout builder module).

Now the tricky thing with layout discovery is, to be discovered by admin and frontend themes, layouts must live in the module space and not in the theme space.

Some of our layouts have JS assets attached which need to know if they are in admin mode or not (e.g. I only fire autoplay behaviors of carousel layouts in frontend, or a MutationObserver triggers a reflow event when an editor adds or removes components in an masonry layout).

Code example:

my_module/js/carousel_layout_asset.js:

((Drupal, drupalSettings, once) => {
  Drupal.behaviors.splide = {
    attach: function attach(context, settings) {
      if (!drupalSettings.path.currentPathIsAdmin) {
        once('splide-js', '.splide', context).forEach(elem => {
          let splideInstance = new Splide(elem);
          splideInstance.mount();
        });
      }
    }
  };
})(Drupal, drupalSettings, once);

This surely can be solved with other ways, but this solution would be theme-independent and does not require me to split code into between an admin part and a frontend part.

But I also don't know how to deal with #7

Alright, so, I'm experiencing the same bug and the current MR/patch fixes the bug.
While the current patch might need some further work, I'll still apply it to the buggy project.

Here's how to reproduce:
- Install https://www.drupal.org/project/choices → and configure it to be only active for the frontend theme
- Install https://www.drupal.org/project/chosen → and configure it to be only actice for the backend theme
- Edit a paragraph with a select field (e.g. an entity reference) -> it now shows two selects (one with choices and one with chosen)
- Applying the patch and clearing the Drupal cache fixes the issue

I'm also adding the current state of the MR as a static file to be used in Composer patches in case the MR gets updated or rerolled.