Open the "discard changes" dialog in the off-canvas tray

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.

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?

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.

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.

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

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

thanks

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

Layout Discard changes opened in the dialog box.

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

Left some comments on the MR

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

Hi @smustgrave!
Could you provide a couple examples or give me direction, where i can have a look and read about

type hints should be included

I didn't clear understand your message.

Thank you.

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 +

Feedback from #20 appears addressed

I've attached the gin-lb version patch for d10.3:

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.

Rebased but hiding the patch as that triggered the bot.

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

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

Rebased

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

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

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.

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

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

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2025-05-09 Active . 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…

In Olivero you see even less Discar…:

If you replace the h1 wrapping the title of the dialog modal with a span with devtools, the title becomes fully legible:

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. 📌 Update to jQuery 1.14.1 and use the newly added option for dialog modal headings Active 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.