Problem/Motivation

Since #3528205: Performance: On-demand lazy-loading source selector, clicking a prop's cog opens its source form in a Drupal.dialog. That fits hosts like Layout Builder or the field form, but not builders that edit in a side panel, like Display Builder:

  • The user clicks in the side panel, and the form opens in the middle of the screen. It covers the canvas, where the change is rendered.
  • With themes replacing Drupal.dialog, like UI Suite Bootstrap, the dialog cannot be moved.
  • The dialog has to stay inside the form so its fields are submitted. Inside a side panel, it then inherits the panel's stacking context and can end up under the host's toolbar.

The inline flow already exists: the server renders the open row in place, and js/source-selector.js only moves it into a dialog. Nested rows already open inline, and no_js.spec.ts covers the inline flow.

Proposed resolution

Let a host opt out of the dialog by marking its form, for example with data-uip-source-inline. Inside such a host, the behavior skips openDialog() and does not set aria-haspopup="dialog" on the cog, the same way it already treats nested rows. The row then opens and closes in place.

Remaining tasks

  • Agree on the attribute name, or use a form property / drupalSettings flag instead.
  • Patch js/source-selector.js.
  • Add a Playwright case: with the attribute set, the cog opens the row inline, with no dialog.

Issue fork ui_patterns-3622509

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mogtofu33 created an issue. See original summary.

mogtofu33’s picture

mogtofu33 commented
Category: Task » Feature request

mogtofu33 opened merge request !563

mogtofu33’s picture

mogtofu33 commented
Status: Needs work » Needs review
just_like_good_vibes’s picture

just_like_good_vibes
Location PARIS
commented
Assigned: Unassigned » just_like_good_vibes
Status: Needs review » Needs work

Hello,
i understand here you don't like the fact that a dialog is opening for complex prop sources, but it is not incompatible at all with builders having a side panel like display builder, especially when components have a lot of props and scrolling is becoming frustrating.
Default widgets are there and directly usable. advanced usage currently triggers a dialog.

We understood your request, and a fallback would probably be made if the dialog is kept.
But dialogs are a temporary solution, until something better is found. The issue #3528205: Performance: On-demand lazy-loading source selector was about performances, with necessary changes on the interaction. Yes, we ended up with a dialog on the current dev branch, but no tag will be made yet until our planed ongoing discussions would take place in another ticket about the new UI/UX. We already discussed several times the possibility of keeping the forms inline.

so the current MR ! 563 is not an option right now, we wait for the upcoming ticket and discussions about the UX/UI.
We will make sure a good compromise is found.

pdureau’s picture

pdureau commented

Yes, we ended up with a dialog on the current dev branch, but no tag will be made yet until our planed ongoing discussions would take place in another ticket about the new UI/UX.

Indeed, it was just the first of the 2 steps, focused on asynchronous load for better performance. It was the hardest part, it is done.

I will try to better communicate this kind of changes to our beloved downstream next time 🤗

I will create the follow-up ticket today or tomorrow with at least 3 proposals:

  • No collapse details anymore, they may not ne necessary now we have a streamlined form
  • Inline AJAX replacement instead of modal (so related to the current ticket of I understand right)
  • Settings Summary displays

As Mikael said, not tag/release will be done without addressing UI.