ConfirmFormInterface::getCancelRoute() should always return Drupal\Core\Url

1. +++ b/core/tests/Drupal/Tests/Core/Form/ConfirmFormHelperTest.php
   @@ -82,6 +83,28 @@ public function testCancelLinkRouteWithParams() {
      /**
   +   * Tests a cancel link route with a URL object.
   +   */
   

   Is there a reason to not actually use @covers ?

2. +++ b/core/tests/Drupal/Tests/Core/Form/ConfirmFormHelperTest.php
   @@ -82,6 +83,28 @@ public function testCancelLinkRouteWithParams() {
   +    $cancel_route = new Url(
   +      'foo_bar/{baz}', array(
   +        'baz' => 'banana',
   +      ),
   +      array(
   +        'html' => TRUE,
   +      )
   

   This is NOT a valid route name. HTML also does not make sense on an URL object.

Hm. I wanted to RTBC this, but then I noticed that a positive/successful form submission uses getCancelRoute() as the redirect target...

It basically re-purposes getCancelRoute() to not only be the route for the "Cancel" link, but also the route for a successful operation? That seems a little bit weird, no? Or is that documented somewhere?

Would it make sense to simply add a new getRedirectRoute() method to the base class that - by default - internally calls into getCancelRoute(), but which essentially ensures that the two (vastly different) conditions are properly covered in the public API?

Oh sorry, I missed that this is not a default/automation - just some classes are internally calling their own method to… not duplicate code (?), I guess.

My comment in #11 would only make sense if there was an automated default route, in which case it would be weird if the redirect route after successful submission would default to the cancel route.

Down with ArrayPIs! :P

Committed and pushed to 8.x. Thanks!