Add a Cancel link on forms

Subscribing, adjusting version

Isn't that what the back button is for?

As long as "Cancel" is a link (back to the node view), that'll work.

Having a specific way to leave edit mode (besides back button, or view tab) is a more typical interface that could provide a less stressful experience for users who aren't Drupal-experienced.

I'd say this could be one small usability improvement that could go a long way. There is already a Delete/Cancel set on delete confirmation pages isn't there?

Sure, I could handle a link. That seems to be what flickr does (the only site I could find one of these on). But no more buttons. oog-lay. :P

We have a cancel link on node delete already, this wouldn't be much of a change.

Here's a patch against HEAD to add "Cancel" links to node edit, and comment forms.

There's some weird alignment going on in the theme that I didn't track down at the moment.

There's some weird alignment going on in the theme that I didn't track down at the moment.

Theming is not an afterthought.

OK, so where is the weird vertical alignment coming from. :)
Changing margins didn't have any effect.. inside node forms it seems any button is positioned nearly a line higher than other elements.

It's only an issue in garland/minnelli, btw.

Here's a variation that applies the "form-button" class to cancel links, and gets around funky browser rendering of margins on buttons by floating "form-submit" and form-button" in the Garland theme.

Please add this! I get quite a few complaints/suggestions to add this functionality. seems like it should be built in. if people are worried about the amount of buttons, get rid of the preview button. just my .02.

I would also like to see a Cancel *link*. It should go to the previously visited page though, and not node/#.

It would certainly be great to see this in core. I've had to add it to my site (Drupal 5.5), and although it's a bit hacky and dependent on client-side JavaScript, this works pretty well in a custom module (handling nodes of type 'event'):

function event_manager_form_alter($form_id, &$form) {
  switch($form_id) {
    case "event_node_form":
      $form['submit']['#prefix'] = '<input class="event-node-cancel" type="button" value="Cancel" onClick="history.go(-1)"/>';
      break;
  }
}

By default, this button appears slightly offset below the save button, so the class is used to align it with the save button:

.event-node-cancel {
  position: relative;
  top: -14px;
  margin-right: 10px;
}

Some of my users in a university environment have also requested such a cancel button. That seems like a valid usability issue.

Those same users also find it strange that some forms have both a submit button and a cancel link rather than two *buttons*. They perceive this as an inconsistency.

I like that, promoting to a usability issue.

Me too. The reality is that when we set up a Drupal site for other people to use, who may be used to finding this "Cancel" button everywhere, I think it would be one less thing for them to figure out as they go about exploring the Drupal site - which could be quite powerful otherwise :) In fact, I would like to see this (even a working patch would be great) in Drupal 6, if that's possible.

I also have been asked for this functionality by users, it's intuitive and feels 'safer' from a drupal novice point of view - a solution would be great.

Can somebody please spell out exactly how to implement Mark B's code? (I'm in 6.x)

For anyone trying to do this in 6.x and earlier, please look elsewhere for a solution. This change will only be implemented in Drupal 7 since it's a new "feature". This patch will add the functionality to Drupal 7, though after seeing it in action I'm not sure if it's any better (though clearly the users here think so).

+1

pressing the cancel button will give the novice user the assurance that their changes won't be saved!

anyways looks good, nice catch on the delete button... just waiting on the testbot, speaking of which... where are the tests!

I love this cancel link.

So now, we have to decide... a link or a button?

I vote button. IMO, the Preview button could become a link, and the Cancel option should be a button. So few people that I've ever trained / supported on Drupal, Joomla, etc. have clicked the Preview button that I don't think it's too important. On some sites, it would be better off gone.

There's a standard in Drupal for buttons vs. links. If an action is going to be performed, it's a button. If no action will be performed, it's a link. Therefor all options to "cancel" in Drupal are links.

One might argue that "Preview" is not an action since it doesn't save, but it certainly has a lot of logic that's necessary and it wouldn't work as a link without JavaScript, since it needs to submit POST information. I don't really think that's an option, but either way it's for a different issue than this one.

We use cancel links on confirmation forms, therefore using cancel links here is consistent with what we already do.

Let's bikeshed link vs. button in another issue.

However, why only node edit forms? Why not user edit forms, or comment forms, or admin forms, or..?

I'd also like to see the usability team chime in on whether or not this is something we should do.

I agree that links are standard (we could change that...but that is another patch, not this one).

I also agree with webchick that we should probably consider adding a cancel link to all forms, since I think the same argument should apply there. That said, I noticed that the usability god Nielsen is against both cancel buttons (although I imagine links would count too) AND reset buttons (although our reset buttons actually do something a bit different, perhaps a potential cause of confusion) - http://www.useit.com/alertbox/20000416.html

In terms of the patch itself:
* '#access' => node_access('delete', $node), looks like it's something for another patch really.
* The "// Generate a URL for the cancel link." comment could be more descriptive - the order is that we should go to a destination if one is set, if not then the node page, and if this is a new node then we go back to the front page.
This should be a link, for consistency. If we want to make all cancel links into buttons that discussion should be in a different issue - not here!

As quicksketch says above, this isn't the place to discuss implementing a cancel button in 6.x. I started a discussion about adding a cancel link or cancel button to node edit forms in 6.x in the forum. Please go there for all 6.x-related questions on this topic.

UPDATE: As per webchick's request, I created a feature request for this instead.

@grobemo: Could you re-post that discussion as an issue instead? The forums are all but invisible to core developers, who focus on the queue. And this would allow us to tag it so it's visible to the relevant parties.

@#24
in my opinion, canceling an action is also an action, since you actively choose to preform the action "no action" or better said "cancel the editing". (hope that makes sense)

http://www.useit.com/alertbox/20000416.html

"Offer a Cancel button when users may fear that they have committed to something they want to avoid. Having an explicit way to Cancel provides an extra feeling of safety that is not afforded by simply leaving.

as we might upload stuff etc. during node creation, we should be able to cancel that too (when uploaded but not saved) (but that's for another issue to implement.)

To give a quick usability review, this is functionality that is not necessary. One can assume the context of a web application to be the same as that of a normal application with model dialogs, but it is quite different as usage of the back button is a more likely scenario and would not confuse the user(#26) - unless the edge case occurs of a user who has rarely used the web or any web form occurs, as suggested in some of the comments.

I am for once with Mr. Nielsen on this one, that cancel buttons are not needed in almost all cases.

On the other question, of why not on all others. Because it should only be exposed to critical forms that can be encountered by the complete beginner on the web.

I disagree. As someone with a background in user experience design and a fan of most of Nielsen's principles, I'd have to say the particular Alertbox article is outdated. The line between online applications, desktop applications and websites has faded, since Nielsen wrote his article. Desktop applications look like HTML pages and vice versa. And the distinction is getting thinner, with all the widgets, html like desktop applications and Adobe Air based tools.

Implementing a CANCEL button or link as part of a themed EDITABLE form is now common practise within all of our projects. In fact, I get questions from clients on all of the forms we 'forgot' to include a CANCEL button/link. Users have come to expect it.

Closed #371109: Adding cancel link/button to node edit forms in 6.x as a duplicate.

Identified on a larger level at UB Usability Testing: http://www.drupalusability.org/node/104

Users expect to be able to cancel out of forms, returning to previous page.

I can only add my personal perspective here. I *know* that hitting the back button should be fine. But still, when I actually changed something in a form and want to undo/cancel that, it doesn't feel really good. So, I'd like to see this explicit Cancel link ( yes a link, not a button).

I don't think this issue is really what is needed or not needed. Lot of times we do things even though they are not needed, just so that we are sure that it happened.

Similarly, Cancel button is one such feature which can make a user feel confident in doing things, rather than trying an unnatural action of hitting browser's back button, when the natural course of action should be to click cancel.

+1 for having a Cancel button.

Another +1 for the Cancel button. It would improve usability and is needed (IMO) for the Checkout module since backing out of page doesn't release a checked out content page.

(Edit: and a proper url for the cancel - not a Javascript implemenation)

Still needs screenshot, if we do decide to do this - make it a link.

You have the View tab. And it was detaield already in the issue we do not want this. #26, #31.

@chx - Those were two of the only comments out of many in this thread that were replying in the negative. A lot of people are used to cancel buttons, and think that if they've entered something, then it's stored in the system unless they click 'don't save' or 'cancel' - I think at least having a Cancel link next to the Save, Preview and Delete buttons would be fitting.

+1 for a) a cancel button, and b) a button, not a link. For me, I know I can just hit back, but then, I'm a web dev... All 4 people on one of my content teams, have, at different times, asked 'where is the cancel button?', 'how do I cancel without saving?' and 'shouldn't that be a button, not a link?'. All of these people use the web regularly, but that doesn't mean that they are 100% confident that pressing the back button in their browser will not do something that they are not expecting. If they want to cancel their action within the scope of the web application, then they should be provided that option with 100% clarity that that is what will happen, and nothing else - a cancel button would do just that.

I've searched for one hour in the core queue, killed a bunch of other issues while being there, but still was not able to find the related issue I was looking for:

1) Form buttons should be wrapped in an additional container to achieve a consistent styling, but also allow for a "Cancel" link, as contained in confirmation forms (which use additional tweaks to get the styling right). Wrapping form buttons into a parent element 'actions' (or similar) also allows for additional styling, for example, applying CSS Sliding Doors to buttons and links to achieve a more modern look.

2) Invoking Form API, but not doing something sounds like overhead to me. Cross-referencing 1) - if all we want is to have it look like a button, but no real form processing is required, then Sliding Doors are a valid option.

3) We may only need a real button, if we start to move CTools's static object caching and locking into core. By pressing a cancel button, CTools unlocks the edited object and forgets about any changes made to the statically cached, but not yet saved object.

Those are great suggestions sun, I'd love to have a consistent wrapper around buttons (even if it didn't provide extra markup). form-submit-buttons.tpl.php?

Yes, excellent. The consistent wrapper around form submits is something I've been missing, too.

And re: cancel action. Make it a link. not a button. This is not a suggestion but an order :)
Why? Because this is a typical 80/20 scenario: 80% (at least!) of the time you'll want to hit the submit/save button. Maybe 20% (max!) of the time you want to cancel. Thus, make the submit/save visually more important than the cancel action: Submit = button, Cancel = link.

Hahah, militant yoroy! Anyway, it seems unlikely that we'll add a cancel link/button universally anyway since we're nowhere close to consensus on this. Let's make this button wrapper and make it possible to easily add a cancel link (or button) to any set of buttons by overriding theme_buttons or form-buttons.tpl.php. Make a $cancel_url variable available regardless of whether it's used or not, and only show it when the original module specifies $cancel = TRUE.

Quicksketch: agreed! :-) The scenario you describe is much more flexible and in line with what core should provide.

Well. It's not that it would not be possible today already ;)

/**
 * Implementation of hook_form_alter().
 */
function custom_form_alter($form_id, &$form) {
  // Add container around form buttons.
  $form['#after_build'][] = 'custom_form_after_build';
}

/**
 * Form after build handler; Wrap buttons in additional container in all forms.
 */
function custom_form_after_build($form, $form_values) {
  uasort($form, "_element_sort");
  // System settings forms.
  if (isset($form['buttons']) && is_array($form['buttons']) && !isset($form['buttons']['#type'])) {
    $actions_start = $actions_end = 'buttons';
  }
  // Confirm forms.
  elseif (isset($form['actions']) && is_array($form['actions']) && !isset($form['actions']['#type'])) {
    $actions_start = $actions_end = 'actions';
  }
  // Abuse abuses 'op'.
  elseif (isset($form['op']) && is_array($form['op']) && !isset($form['op']['#type'])) {
    $actions_start = $actions_end = 'op';
  }
  // Try to determine form buttons manually (first level only).
  else {
    foreach (element_children($form) as $item) {
      if (!is_array($form[$item]) || (isset($form[$item]['#access']) && !$form[$item]['#access'])) {
        continue;
      }
      if (isset($form[$item]['#type']) && ($form[$item]['#type'] == 'submit' || $form[$item]['#type'] == 'button')) {
        if (!isset($actions_start)) {
          $actions_start = $item;
        }
        else {
          $actions_end = $item;
        }
      }
      else if (isset($actions_start) && (
        (!isset($form[$item]['#type']) && isset($form[$item]['#value']))
        || ($form[$item]['#type'] == 'markup' && isset($form[$item]['#value']))
      )) {
        $actions_end = $item;
      }
    }
  }

  if (isset($actions_start)) {
    $form[$actions_start]['#prefix'] = '<div class="form-actions">' . (isset($form[$actions_start]['#prefix']) ? $form[$actions_start]['#prefix'] : '');
    if (!isset($actions_end)) {
      $actions_end = $actions_start;
    }
    $form[$actions_end]['#suffix'] = (isset($form[$actions_end]['#suffix']) ? $form[$actions_end]['#suffix'] : '') . '</div>';
  }

  return $form;
}

Obviously, that code works for Drupal 5.x. Also nicely catches any appended text links after form buttons.

Obviously, we don't want something like that in core.

All we can do in core is set up a best practice, i.e.

  $form['actions'] = array('#theme' => 'form_actions');
  $form['actions']['preview'] = array('#type' => 'button', '#value' => t('Preview'));
  $form['actions']['submit'] = array('#type' => 'submit', '#value' => t('Save'));
  $form['actions']['cancel'] = array('#markup' => l(t('Cancel'), referer_uri()));

  return $form;

reason why not to use an link: "uneditable" nodes.
<img src="/node/%/edit/cancel" /> (where % is the number of the current node.)

see also: #144538: User logout is vulnerable to CSRF

+1 on cancel BUTTON. Has been requested by users on two sites I am involved with.

thanks!

-T

Let's do the consistent wrapper around form submits first: #482816: Make a consistent wrapper around submit buttons

+1 for the button! As a user experience guy, I think a cancel button is an absolute necessity.

1. Spatially speaking, the buttons that make a form do something are at the bottom of the page and the back button is in the upper-left side of my browser window, completely outside the frame of the web application I'm using. When I'm using a web application my mind is in the application. I rarely think about the browser. A good web application should be as self-sufficient as possible and not rely on the browser—a completely different application—for its functionality.
2. Years of experience using online applications and forms have taught me that hitting the back button can have unintended consequences. Again, the browser is a different application and how its functions will interact with the application inside the window is often an unknown. My instinct is to use the web app's UI whenever possible. If a needed function does not exist within the UI then I need to stop and think about it, which is bad.
3. Many of the people who will be using the CMS I'm developing are not even remotely technical. Forms scare them. It doesn't matter whether a cancel button actually does anything or not. It feels like there should be one and many users will look for one, therefore there should be one. Fulfilling users' expectations is an important part of UI design and should not be trivialized, even if those expectations are unnecessary.
4. When I cancel a node edit I am most definitely performing an action. I am undoing whatever I did when I called up the form to begin with, and whatever I may have already entered in it, and I am putting things back the way there were before. Perhaps in reality there is nothing to undo, but that's besides the point. As a user I have no idea how Drupal works behind the scenes. I probably don't even know the application I'm using is based on Drupal (whatever that is). I just know I've been messing around in this form and now I want to undo whatever I did. This deserves a button. Hierarchically, within the UI, it should be on the same level as Save or Delete.
5. If you're worried about people accidentally pressing Cancel instead of Save, then:
   • Put some physical space between the Save/Preview buttons and the Cancel/Delete buttons.
   • Visibly highlight the Save button.
   • If the user has made any edits on the page then a warning dialog should appear when they click Cancel.

FYI: Some progress in #482816: Make a consistent wrapper around submit buttons.

As mentioned before, links can be styled as buttons. We might as well introduce a new #theme function to allow for consistent styling of links that appear next to form buttons.

Form buttons currently have another flaw: They trigger form validation (e.g. for required elements, but also custom validation functions). See for example #438298: Allow for custom #required validation, but I still believe there is another issue focusing on this issue.

button? OUCH. If you insist on this ( i stil dislike the idea ) then a link.

I'm with chx on this issue now; after seeing many sucessful implementations of the cancel link (like Flickr, Google, Facebook, etc.), I think that'd be the way to go.

I'm with chx too- far better to use links for GETs and Form Submits for POSTs. For D6 I used this in hook_form_alter() to good effect:

$form['buttons']['cancel'] = array(
'#type' => 'markup',
'#value' => l(t('Cancel'), referer_uri()),
'#weight' => 20,
);

--
Real Life Design

hi
faribisch
thanks for ur code
cancel button is working on node edit but i need this button on node creation also how?
on forum topic creation etc
please helpme
this is very urgent for me

it's working
thanks

This has been discussed, somewhat late in the cycle to add this - lets work on this in Drupal 8

I was working with Webform, and I add Cancel button behind Submit button.
If you have only one page that is what I have, you need add the code under "add the submit button area" in webform.module, like below:

$form['cancel'] = array(
'#type' => 'markup',
'#value' =>'',
'#weight'=> 1003
);

Using this way, you will be able to add any button joint html or javascript together with php, and do more flexible options.

cheers,

I really wish people would stop trying to impose their personal views on everyone else, and simply facilitate a personal choice for the developer of the website - e.g. whether there is a cancel form facility or not, and if there is, whether is it rendered as a button or a link. No matter what YOU personally think, would you like someone else to impose their opposite view on you? No? So don't try and do it to everyone else!!!!

Mind your own business and get a life!!! Better still, help someone else achieve what they want to achieve?

Awesome move, supporting your argument with references to religious wars. Features are frozen, that's simply a fact of the point in the dev cycle we are in. And stop yelling.

simply facilitate a personal choice for the developer of the website

Nearly all of our forms have nicely sectioned-off the "actions" of a form in a separate location (inside of $form['actions'], it's not quite all but that's what #482816: Make a consistent wrapper around submit buttons is for). The mechanism to add cancel links just about everywhere is already in place, though you'd need to decide where the hrefs on those "Cancel" links go on a case-by-case basis. This would be a trivial contrib module, so there shouldn't be any complaining that this isn't possible or that we're imposing a set way on anyone. But as yched said, we'll continue deciding which way is best as the default and put it into the next release of Drupal.

Intuitive.

That should be the overarching design goal driving this discussion. We design our applications expecting users to navigate via the UI elements we provide to them -- and as a result they have come to expect the same. Requiring users to use browser controls to navigate our application means we have failed in our design of the interface.

As developers we become accustomed to using browser controls during the development process -- but rest assured, users of web applications today expect all the necessary navigation UI elements to be present within the application itself. When they are not, it feels 'wrong'. I would expect that polling the developer community on this topic is going to produce drastically different results than polling the application user community.

Make no mistake -- this is not a discussion about functional necessity. Are the UI elements of Apple iPhone's functionally necessary? Absolutely not, but they are highly intuitive (my 5yo niece can navigate any iPhone application with ease).

We can debate the best way to implement and/or theme this functionality, but I honestly believe there should be absolutely no question as to its necessity to promote an Intuitive User Interface.

Subscribing

subscribing for Drupal 6

Hi all. Here is the solution for cancellation required validation. Without links... It's removes #needs_validation attribute for required fields, and validation is being skipped, so you can perform some logic in your cancel submit function. Follow this tutorial http://devengineering.com/best-practices/drupal/cancellation-required-va...

Subscribing for D6

Actually GlossyIbis (#63) is absolutely correct.

This sort of petty refusal to see something from the other perspective, especially when the other perspective is the target audience, is an all too common problem among some technical types. Refusal to make a trivial change that would make life easier for users of a product is an old, boring example of passive aggressive behavior, nothing terribly new or interesting here. But it still takes its toll.

No one is being asked to donate a kidney or a firstborn, just a button for crying out loud. This is some of the same petty stuff that results in each version of Windows moving familiar functions around just because the whiz kids in Redmond want to try something out.

Drupal is fabulous, no doubt about it. And it will become even more so to the extent that this kind of silliness is outgrown.

Some of our users explicitly requested this feature in a usability review of our site, we'd like to bubble the issue upstream since configuration of the cancel link/button visibility and look seems to be entirely missing in the standard Drupal install.
Our suggestion would be to default to a button display of the "Cancel" button, but allow admins to configure it to show as a button, a link or be hidden.

This issue was tagged with the "Needs Screenshot" tag. A screenshot of the expected default behaviour (according to our short user review) is attached. This seems to be in line with what has been suggested so far in this thread.

Also somewhat relevant to this discussion is the More Buttons-module for Drupal 7 and the More Node Buttons-module for Drupal 6 installations. These modules provide some or all of the required functionality (depending on your specific requirements) and may be used as inspirational source or a workaround.

I'd love to see this issue revisited for d8 :)

I'll second that motion. It came up recently during the discussion of #1123696: Does 'Save' publish my content?.

I needed to implement a fix for canceling nodes, and I've contributed my fix here (for Drupal 6):

You need to make a module, and replace MODULENAME with the name of your module, and NODETYPE with the type of node you're attempting to modify.

function MODULENAME_form_alter(&$form, $form_state, $form_id){
	
    
    switch ($form_id) {
      // This is our form ID.
      
      case 'NODETYPE_node_form': 
	  
	  $form['buttons']['cancel'] = array (
	  '#type' => 'submit',
	  '#access' => TRUE,
	  '#value' => 'Cancel',
	  '#weight' => 60,
	  '#submit' => array('node_form_cancel') //This is the name of a function reproduced below
	  );
      break;
      //Continue on with other node forms, replicate for NODETYPE_ONE_node_form, for example 
    }
    
}

function node_form_cancel(){
if ($_GET['destination']){
$backurl = $_GET['destination'];
}else{
$backurl ="front"; //replace with a URL if there is not a destination parameter. 	
}
drupal_goto($backurl);
}

Hope this helps.

@Ronin, want to thank you for your solution works superb!

http://drupal.org/project/mb

#6: edit_cancel.patch queued for re-testing.

#6: edit_cancel.patch queued for re-testing.

#10: edit_cancel_floated.patch queued for re-testing.

mb from #77 is pretty much abandoned, I would recommend people not install it as it does not work out of box on a D7 sandbox I tested.

Does anyone have advice on how to get #75 working for D7?

I ran it through coder and updated the hook_form_alter function per coder's suggestions but it isn't showing on my node type edit form, my node type is "product". Also, how would I modify this to cover all content types? Here is the code I am using:

<?php


/**
  * Adds a cancel button to product edit form
  */

function cancel_button_form_alter(&$form, &$form_state, $form_id) {
    
    
    switch ($form_id) {
      // This is our form ID.
      
      case 'product_node_form': 
      
      $form['cancel'] = array(
      '#type' => 'submit',
      '#access' => TRUE,
      '#value' => 'Cancel',
      '#weight' => 60,
      '#submit' => array('node_form_cancel') //This is the name of a function reproduced below
      );
      break;
      //Continue on with other node forms, replicate for NODETYPE_ONE_node_form, for example 
    }
    
}

function node_form_cancel() {
  if ($_GET['destination']) {
    $backurl = $_GET['destination'];
  }
  else {
    $backurl ="front"; //replace with a URL if there is not a destination parameter.
  }
  drupal_goto($backurl);
}

@Elijah Lynn Thank you.

I've just used it for edit comment and it works successfully.

Restoring issue properties.

mohammadjolani - Was this for D6?

Firstly, what is implemented in #75 must be ported so It should be considered as a patch needed. Therefore, I change the issue properties.

Secondly,

If what is said in #80 is true (and it looks like if you visit the mb project page), there should be changed "Maintenance statuses" to 'abandoned'.

Appart from that... This feature of cancel button... actually we should work on 6.x, 7.x or 8.x? It has been changed so many times that I does not have it clear at all.

Thank you for nice work.

Um, what version has this been committed to that it needs porting? See http://drupal.org/node/156119.

Was also looking at this functionality for a current project. To summarize things up 'til now: some of the main features that a "cancel" functionality might need to account for in core could include:

1) Allow cancel to be a link or a button.

2) If cancel is a link, the link URL should be the referrer_uri() if it exists. When referrer is empty, the logic should work like this: if this is the node edit form and the node already has an nid, the URL should be "node/$nid", otherwise the URL should be "node/add" by default, but this backup value should be configurable per content type.

3) Permit client-side cancel button functionality so that the form is not submitted, simply use JavaScript to redirect to history.go(-1) (eg this implementation).

4) Permit server-side cancel button processing on form submit. This is a fallback for 3 (if enabled) and javascript not present.

5) Provide a general and succinct solution to have a cancel button functionality with confirmation screens (i.e. a confirmation callback) (maybe confirm_form?). E.g. "Do you really want to cancel and lose all your edits? yes/no". The confirmation step should work both via a javascript dialog as well as a fallback to the server-side confirmation page (similar to the Delete screen). The javascript dialog should fire an ajax cancel callback submit (assuming the user confirms) and then redirects to the previous page (history.go(-1)) or the page chosen by the confirmation callback. If the site builder specifies a link (as opposed to a button) and also provides a confirmation callback, then the HTML must serve a button, but it can either be styled as a link with CSS, or be replaced with a link by javascript (with destination '#' and a proper onclick handler to execute the ajax callback before redirecting).

Admittedly #5 is slightly far-fetched and may better be served by contrib, but hey, one can wish and brainstorm... I'd really love to see this ajaxified "confirmation callback" idea standardized as a general solution in core, and extended to the Delete button functionality as well. This is all about improving content editors experience, using modern technology -- who wants to wait these days for an entire page to load just with a confirmation screen?

Moving to 9.x, since this feature hasn't had any patches in several years now, so doesn't meet the qualifications for feature freeze extension.

Hey @Mark B, your solution worked for me.
I was searching for this from one day.
You saved my day.
Thanks Dude!!!

updating issue title.

Is it available yet on D8.9 or not ?