While testing this, I tried to normalise further that modal by adding a Save (apply) button, but it fails, i.e. Save also closes the modal.
Here is my patch. Can you look at what is missing?

diff --git a/administrator/components/com_plugins/views/plugin/tmpl/modal.php b/administrator/components/com_plugins/views/plugin/tmpl/modal.php
index 69d18a3..f1249d5 100644
--- a/administrator/components/com_plugins/views/plugin/tmpl/modal.php
+++ b/administrator/components/com_plugins/views/plugin/tmpl/modal.php
@@ -19,4 +19,5 @@
 ');
 ?>
+<button id="applyBtn" type="button" class="hidden" onclick="Joomla.submitbutton('plugin.apply');"></button>
 <button id="saveBtn" type="button" class="hidden" onclick="Joomla.submitbutton('plugin.save');"></button>
 <button id="closeBtn" type="button" class="hidden" onclick="Joomla.submitbutton('plugin.cancel');"></button>
diff --git a/administrator/components/com_redirect/views/links/tmpl/default.php b/administrator/components/com_redirect/views/links/tmpl/default.php
index 00d0cd0..7986aec 100644
--- a/administrator/components/com_redirect/views/links/tmpl/default.php
+++ b/administrator/components/com_redirect/views/links/tmpl/default.php
@@ -17,4 +17,6 @@
 JHtml::_('formbehavior.chosen', 'select');
 
+$uri       = JUri::getInstance();
+$return    = base64_encode($uri);
 $user      = JFactory::getUser();
 $listOrder = $this->escape($this->state->get('list.ordering'));
@@ -25,5 +27,5 @@
 		<?php echo JLayoutHelper::render('joomla.searchtools.default', array('view' => $this)); ?>
 		<?php if ($this->redirectPluginId) : ?>
-			<?php $link = JRoute::_('index.php?option=com_plugins&client_id=0&task=plugin.edit&extension_id=' . $this->redirectPluginId . '&tmpl=component&layout=modal'); ?>
+			<?php $link = JRoute::_('index.php?option=com_plugins&client_id=0&task=plugin.edit&extension_id=' . $this->redirectPluginId . '&return=' . $return . '&tmpl=component&layout=modal'); ?>
 			<?php echo JHtml::_(
 				'bootstrap.renderModal',
@@ -32,10 +34,20 @@
 					'url'        => $link,
 					'title'      => JText::_('COM_REDIRECT_EDIT_PLUGIN_SETTINGS'),
-					'height'     => '400px',
-					'modalWidth' => '60',
-					'footer'     => '<button class="btn" data-dismiss="modal" aria-hidden="true">'
-						. JText::_("JLIB_HTML_BEHAVIOR_CLOSE") . '</button>'
-						. '<button class="btn btn-success" data-dismiss="modal" aria-hidden="true" onclick="jQuery(\'#plugin' . $this->redirectPluginId . 'Modal iframe\').contents().find(\'#saveBtn\').click();">'
+					'height'      => '400px',
+					'width'       => '800px',
+					'bodyHeight'  => '70',
+					'modalWidth'  => '80',
+					'closeButton' => false,
+					'backdrop'    => 'static',
+					'keyboard'    => false,
+					'footer'     => '<button type="button" class="btn" data-dismiss="modal" aria-hidden="true"'
+						. ' onclick="jQuery(\'#plugin' . $this->redirectPluginId . 'Modal iframe\').contents().find(\'#closeBtn\').click();">'
+						. JText::_('JLIB_HTML_BEHAVIOR_CLOSE') . '</button>'
+						. '<button type="button" class="btn btn-primary" aria-hidden="true"'
+						. ' onclick="jQuery(\'#plugin' . $this->redirectPluginId . 'Modal iframe\').contents().find(\'#saveBtn\').click();">'
 						. JText::_("JSAVE") . '</button>'
+						. '<button type="button" class="btn btn-success" aria-hidden="true"'
+						. ' onclick="jQuery(\'#plugin' . $this->redirectPluginId . 'Modal iframe\').contents().find(\'#applyBtn\').click();">'
+						. JText::_("JAPPLY") . '</button>',
 				)
 			); ?>

Hi, been testing and trying that yesterday. Run into the same issue that the save button when added closes the modal.
This is because (my best guess) the save function does a post of the form and a post closes the modal.
I have not sufficient javascript / jquery knowledge to fix that: that is the reason why I left it out in the first place.

So in short: help needed :)

Also, I guess we do need to add a conditional
if ($user->authorise('core.edit', 'com_plugins')) etc.

Agree but I think that (authorization check and Apply button) are out of scope for this commit which addresses the incorrect close behavior.

@Ruud68 can you please test again? I tested without PR and Step 4 and 5 works as expected (Plugin is enabled in Tab 1).

@franz-wohlkoenig true, it enables the plugin, but that is not what this fix is fixing. It fixes the ability to close the modal and by doing that bypassing the proper close function: the plugin is checked out. That means that another administrator cannot handle it anymore

If in that Scenario in Tab 1 the Redirect-Plugin is enabled even "Close" is used in Modal its a successfully Test?

Hi, let me explain with video: https://office.onlinecommunityhub.nl/nextcloud/s/Aa94YsNtXY377vB

1. close button, no checkin of plugin (plugin is checked out to super user)
2. X , no checking of plugin
3. click on backdrip (outside modal), no checkin of plugin
4. then save and close button: Yeay, plugin is checked in.

After my patch:
1, close button > plugin correctly checked in
2. X > not possible (there is no X)
3. click on backdrop: disabled
4. click save and close > same as before

@Ruud68 another way to solve this without removing the X button and forcing the backdrop is to setup a listener for the Bootstrap Modal hide event and then click on the cancel button on the modal Iframe. Something like:

$doc->addScriptDeclaration(
"jQuery('#plugin" . $this->redirectPluginId . "Modal').on('bs.modal.hide', function(e) {
     jQuery('#plugin" . $this->redirectPluginId . "Modal iframe').contents().find('#closeBtn').click();
});"
);

@dgt41 I have considered that, but I 'decided' to standardize and use the same config for the modal as the edit article modal in the menu 'Single article'.
I am only utilizing the variables that are already present, so no need to add code (and maintain it).

I have tested this item ✅ successfully on fe1e7d6

Thanks for Patience, @Ruud68

@franz-wohlkoenig Top!
Now waiting patiently for second test :)

@infograf768 do you have Time for 2nd Test?

To be normalized (even if we can't add Apply), the code still needs imho to be modified to get

+					'height'      => '400px',
+					'width'       => '800px',
+					'bodyHeight'  => '70',
+					'modalWidth'  => '80',
+					'closeButton' => false,
+					'backdrop'    => 'static',
+					'keyboard'    => false,
etc.

Hi, as said before: this change is not about normalizing, but is a fix for a bug.
I agree that things need to be normalized, but that would then need investigation of what normal is, and things need to be tested on multiple devices (how do the height and width that are put here as an example behave on mobile devices, etc.
For me that is (way) beyond the scope of this 'quick' fix and should be addressed in a separate PR... or not :S

While correcting a bug, if code has to be normalized at the same time, one should do it instead of creating a new PR. Cost is little and saves time for testers.
See
https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_content/models/fields/modal/article.php#L197-L218

@infograf768 agree, but... that code limits the usage on mobile devices, so normalizing would not be an option for me. The way to go when normalizing is that it is normalized so that it will work cross device.
That (for me) is no little cost as that would involve looking at all modal code and all use cases / devices.

Anyway, the whole discussion regarding this simple patch (mind you, my first step to becoming a contributer) is taking so much time and attention that I could have normalized all modal code.
That is why I now stop putting time in this PR: feel free to test or not.

I have tested this item ✅ successfully on fe1e7d6

I don't want to discourage you. Maintainers will decide. Test OK here.

Ready to Commit after two successful tests.

@infograf768 Here you go: normalized and save (apply) button :)
#18913