Problem/Motivation

If you currently click on the "Discard changes" button in the Layout Builder, you will be forwarded to a separate page to confirm the dialog. I think it's the same for the "Revert to Default" button.
I'm wondering if there's a particular reason why these dialogs are opened on a separate page.

Otherwise, wouldn't it be a better UX to open those dialogs in the off-canvas tray like all the other Layout Builder dialogs to keep things consistent?

Steps to reproduce

  1. Create a layout with the Layout Builder.
  2. Click on the "Discard changes" button in the Layout Builder.
  3. Find yourself on a page with URL pattern /node/[nid]/layout/discard-changes to confirm the dialog.

Proposed resolution

I'd expect those dialogs to be opened in the off-canvas tray.

Remaining tasks

Discuss if opening those dialogs in the off-canvas tray is a good solution.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

Issue fork drupal-3223022

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:

Comments

design.er created an issue. See original summary.

design.er’s picture

Version: 9.2.x-dev » 9.3.x-dev

Correcting targeted Drupal version.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

strykaizer’s picture

StatusFileSize
new2.15 KB
new2.16 KB

Attached is a fix which opens both discard changes and revert to defaults in a dialog.

I added an extra patch for people who use gin/gin layout builder, which ensures the buttons are rendered nicely.

tim-diels’s picture

Status: Active » Needs review

The patch works as expected.

But can we do the width of the modal different? I looked up in Drupal core and mostly 880 px is used.
The FieldUiLocalAction is using 85vw which seems much better to implement then hard pixels?

The normal patch is probably what is needed and a follow up ticket will be needed in Gin Layout Builder to cover the classes on the button?

tim-diels’s picture

Status: Needs review » Needs work

Still small nitpick:

+++ b/core/modules/layout_builder/src/Form/OverridesEntityForm.php
@@ -193,21 +194,27 @@ protected function actions(array $form, FormStateInterface $form_state) {
+    $actions ['discard_changes'] = [
...
+    $actions ['revert'] = [

There must be no space before the bracket.

kalanh made their first commit to this issue’s fork.

kalanh’s picture

StatusFileSize
new1.63 KB

The patch from #7 no longer applies, but I think this would be a sensible UX enhancement. I have pushed an issue fork and attached a patch for gin_lb users.

man-1982 made their first commit to this issue’s fork.

man-1982’s picture

Looks like MR ready to review!
Dear Colleagues please you take a look.
Thanks

man-1982’s picture

Status: Needs work » Needs review
man-1982’s picture

I've prepared some proof that MR does work. I used clean installation Drupal 11.

proof of fixing

thanks

manibharathi ezhimalai ravi’s picture

StatusFileSize
new11.57 MB
new15.83 MB

Hi,
I've reviewed the MR !9183 on Drupal 11.x.

Layout Discard changes opened in the dialog box.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

Just checking issue summary it appears to be incomplete, UI changes should be placed

Left some comments on the MR

man-1982’s picture

Status: Needs work » Needs review
smustgrave’s picture

Status: Needs review » Needs work

If they’re new functions being added type hints should be included. Unless it’s a base method that would require updating all spots.

man-1982’s picture

Hi @smustgrave!
I understood you message to me.

Going to fix.

thanks

man-1982’s picture

Status: Needs work » Needs review
sheetal.pathak’s picture

StatusFileSize
new15.8 MB
new22.78 MB

Reviewed latest MR ,it applies cleanly and MR resolves mentioned issue.

Drupal version 11.x-dev

1. Create a layout with the Layout Builder.
2. Click on the "Discard changes" button in the Layout Builder.
3. Before MR, it would redirect to /node/[nid]/layout/discard-changes to confirm the dialog
4. After applying MR is opens in dialogue box.
5. Attaching screenshot for before and after.
Issue can be moved forward.
RTBC +

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Feedback from #20 appears addressed

kalanh’s picture

I've attached the gin-lb version patch for d10.3, but it needs work.

needs-review-queue-bot’s picture

Status: Reviewed & tested by the community » Needs work
StatusFileSize
new123 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

smustgrave changed the visibility of the branch 11.x to hidden.

smustgrave changed the visibility of the branch drupal-3223022-3223022-modal-discard-dialog to hidden.

smustgrave’s picture

Status: Needs work » Reviewed & tested by the community

Rebased but hiding the patch as that triggered the bot.

man-1982’s picture

Hi gays,

i'de like to ask what we decided about patch?
Do we need more extra tests or works?

it would be my pleasure to help with this one.

thanks

nod_’s picture

Status: Reviewed & tested by the community » Needs work

sounds like a good idea. there is a merge conflict to resolve first

smustgrave’s picture

Status: Needs work » Reviewed & tested by the community

Rebased

catch’s picture

Status: Reviewed & tested by the community » Needs work

Has another merge conflict - didn't actually review the change yet.

dcam made their first commit to this issue’s fork.

dcam changed the visibility of the branch 3223022-modal-discard-dialog to hidden.

dcam’s picture

Status: Needs work » Reviewed & tested by the community

I don't know what's wrong with MR 9183. GitLab reports that it can't be rebased onto 11.x, but it clearly can. It just seems to be broken. I wondered if applying the changes to another branch would work. So I exported them to a patch and opened MR 11723. GitLab doesn't have any problem with it.

Restoring RTBC status.

catch’s picture

Issue tags: +Needs usability review

Tagging this for needs usability review, the issue summary could use an update to indicate why this change is being made.

rkoller’s picture

i can put the issue on the shortlist for the ux meeting on friday. just one question upfront and one remark. is it an intentional behavior that the discard changes dialog is only shown on the layout for a node/content item, but when i discard a change on the layout of a content type i still get to a confirmation page? and i guess the MR needs a rebase because of the recent renaming changes in package_manager, on drush cr i get PHP Fatal error: Uncaught Error: Class "Drupal\package_manager\SandboxManagerBase" not found in /var/www/html/repos/project_browser/src/ComposerInstaller/Installer.php:14

rkoller’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: -Needs usability review +Needs issue summary update
StatusFileSize
new140.45 KB
new128.93 KB
new183.22 KB

Usability review

We discussed this issue at #3522326: Drupal Usability Meeting 2025-05-09. That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @benjifisher, @rkoller, @simohell, and @worldlinemine.

There was a clear consensus within the group that using a dialog modal instead of forwarding to a dedicated confirmation page is a desirable improvement. Forwarding to a confirmation page is only preferable in case additional tasks/steps are necessary to take, but for an informational confirmation step, staying within the context of the page the confirmation is required on, a dialog modal is the better choice. But we found a few details that need further work:

1) The title of the dialog modal is getting truncated. In Umami you only see: Discard cha…

a layout page in the umami theme for the node give your oatmeal the ultimate makeover showing a confirmation dialog modal with a truncated title discard cha...

In Olivero you see even less Discar…:
a layout page in the olivero theme for the node experiment showing a confirmation dialog modal with a truncated title discar...

If you replace the h1 wrapping the title of the dialog modal with a span with devtools, the title becomes fully legible:
a layout page in the olivero theme for the node experiment showing a confirmation dialog modal with the title discard changes

Some context, until a few weeks ago, a span element was used for wrapping the title of dialog (modals) in jQuery UI in Drupal, which was semantically wrong and a problem for screenreader users.#3485202: Change the element wrapping the title in dialogs from span to heading element solved that problem, for dialogs the span got replaced by h2s, and for dialog modals by h1s. In Claro that change caused no visual changes, but I was unaware that dialogs and dialog modals would be available for frontend themes like olivero and umami as well, and therefore have not tested for that detail, which lead to results seen in the screenshots. :/

It would be necessary to open up issues in the Olivero and the Umami issue queue for fixing the truncation of the title. Aside the truncation there are a few more problems with those dialog (modals). The close button has a too small target size (16x16) for Olivero and Umami, the required minimum target size to meet WCAG2.2 SC2.5.8 would be at least 24x24 pixels. Then in Umami the confirm button has a too low color contrast and is not meeting the required color contrast of at least 3:1 to comply with WCAG2.2 SC1.4.11. Also in the context of WCAG2.2 SC1.4.11 the dialog component is not easily recognizable nor distinguishable from the background - in Claro you have at least a visually more clearly darkened background and the dialog modal sort of “stands out” from the background. The last point to note is in regard to the general layout, the dialog modals in Umami as well as Olivero are missing some padding, the content and the buttons feel cramped into the dialog component.

2) At the moment the confirmation dialog is only available for layout overrides on nodes, the default layout for a content type still employs confirmation pages (as noted in #39). There was the clear consensus to make things consistent and use confirmation dialogs on default content types as well. If that change could be done easily it would be good to fix that within the scope for this issue, if it would be a more complicated endeavor it could also be moved to a follow up. And on a side note, by switch to the confirmation dialog on the default layout for a content type, those overly conversational verbose titles could be avoided, that are currently used on the confirmation page (it uses Are you sure you want to discard your layout changes? as the title). Titles should always provide immediate clarity of context and action to be taken in a concise manner - for single task titles like that, with imperative verb phrases.

3) The issue title needs to be updated. Currently it refers to opening the dialog in the off-canvas tray, but with the MR the confirmation dialog opens in a dialog modal instead. The user interface changes section in the issue summary also needs before and after screenshots. Therefore I am adding the Needs issue summary update tag.

I set the status to Needs work for now, until it is decided what the preferable order for fixing those three points is. One thing to note, in regard to point 1, the suggestion/idea during the meeting was, to postpone this issue until the to be created issue(s) in the theme queues are being fixed - question also is should there be several tightly scoped issues for truncation, target size, color contrast, and padding per theme or should some of them be combined? And it should also be checked if Olivero for Drupal CMS would require additional fixes after Olivero is being fixed.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

rkoller’s picture

richarddavies’s picture

I'm also seeing issues caused by the dialog title changing from a span to a h1 in other frontend themes such as Radix. We use the Admin Dialogs module, which turns certain actions into a dialog, such as deleting a node. The new dialogs now have a giant truncated title, same as reported for the other frontend themes.

I'm guessing this is now a problem for all frontend themes, so is there a better way to report or fix this instead of a separate issue for each theme?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.