[UX][META] Smart redirects for the "cancel" button.

[klonos]

I bumped into this situation while trying to fix #2264...

When editing an existing content type, there are two submit buttons available, one to save the content type and one to delete it. The delete button takes the user to a confirmation page before doing the actual deletion, but if the user has pressed the delete button by mistake and hits the cancel button/link in the confirmation page, they are then redirected to the page with the list of content types instead of the content type they were editing. Any changes made to the content type configuration are lost (hence the bug tag on this issue).

Now, the redirection of the delete content type confirmation page makes sense if the user has clicked the delete dropbutton available from the content type "Operations" column in /admin/structure/types, but not when they have clicked the respective delete button in the content type edit form. We should be smart about this and have separate redirects for these two cases. We should also consider tempstore for content types (to prevent loss of config changes and bad UX) ...or make the delete confirmation dialogs open in modals (#769).

So, basically current behavior is this:

• Edit existing content type -> hit the delete button -> hit the cancel link -> redirect to /admin/structure/types 👎
• Go to /admin/structure/types -> select the delete option for one of the content types -> hit the cancel link -> redirect to /admin/structure/types 👍

...proposed change is this:

• Edit existing content type -> hit the delete button -> hit the cancel link -> return to content type configure page (instead of redirecting to /admin/structure/types)
• Go to /admin/structure/types -> select the delete option for one of the content types -> hit the cancel link -> redirect to /admin/structure/types (unchanged)

[klonos]

...making this a meta-issue because there might be other forms in the UI that have the same or similar issues.

[klonos]

...this would be much simpler (or perhaps even a non-issue) if the delete confirmation page was converted to be a modal with a cancel button for both the individual content type configure forms as well as the manage content types page.

[mikemccaffrey]

Switching the delete confirmation to a modal would make sense.

Since any form changes are lost when you hit the delete button and leave the page, taking the user back to the form may confuse them into thinking that that is not the case. Or perhaps there is a way to save the form state and return to it on cancel?

[klonos]

Since any form changes are lost when you hit the delete button and leave the page...

Maybe that shouldn't be the case then. Why would we not keep the changes for the case when the user has accidentally hit the delete button (and then canceled)?

Anyways, as I said I think that putting the delete confirmation in a dialog would make things simpler: user hits delete (either accidentally or on purpose) -> nothing happens other than a dialog popping up. No changes lost, no need to store them either. User confirms -> content type is deleted altogether. User cancels -> nothing happens to the form, just the dialog disappears.

[quicksketch]

The cancel link could also be fixed just by adding a destination query string to the URL, then that gets used automatically on the Cancel link by the code in confirm_form(). So that'd be a basic improvement we could do that would be a one-liner.

Regarding restoring the user's entered data, I also agree that a dialog would make a lot of sense here and would be more straight-forward to implement. We should be able to do this by adding a #ajax property to the delete button. Then adjust the confirm_form() function to add matching #ajax abilities to deal with any validation failures on submit and handle the redirection.