I have check on Alloy template and it is working on lastest Forms. The URL looks like: "?__FormGuid=002c5114-0410-4f45-9c43-2b6ab5cb5f15&__FormLanguage=en&__FormSubmissionId=54d92b26-90fe-466e-85bb-2f7590464c18" for both js and non-js mode. Could you try to reproduce on the alloy template and if it work or not?

Thanks for the reply.

I also can't reproduce on latest Alloy. I don't think its necessarily a bug with the core Forms product. I was just trying to get an idea of where might be a good place to start. Redirection happens fine, its just any additional parameters aren't added.

I guess I'll start transfering our custom form implementation to the latest Alloy to see if I can reproduce - we have a fair few extensions, custom actors, external system information mappings, custom form blocks etc etc. I was just hoping there might be an obvious place to start or logging that might help

Our custom actor is feels like the right place to look at as this has IsSyncedWithSubmissionProcess = true and so modifies the response. 

Update: I've found this exception appears on Form submission, which feels related, though I'm not sure what the content link that could be missing is

System.ArgumentNullException: The provided content link does not have a value.
Parameter name: contentLink
   at EPiServer.Core.Internal.DefaultContentLoader.Get[T](ContentReference contentLink, LoaderOptions loaderOptions)
   at EPiServer.Web.Routing.Internal.DefaultSimpleAddressRouteHandler.GetContentReference(UrlBuilder urlBuilder, SegmentContext segmentContext)
   at EPiServer.Web.Routing.Internal.DefaultSimpleAddressRouteHandler.GetRouteValues(String urlSegment, ContentReference routeRoot, SegmentContext segmentContext)
   at EPiServer.Web.Routing.Segments.Internal.SimpleAddressSegmentRouter.ResolveContentForIncoming(ContentReference contentlink, String urlSegment, SegmentContext context)
   at EPiServer.Web.Routing.Segments.Internal.SimpleAddressSegment.GetIncomingNode(ContentReference contentLink, SegmentContext context)
   at EPiServer.Web.Routing.Segments.Internal.SimpleAddressSegment.RouteDataMatch(SegmentContext context)
   at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   at EPiServer.Web.Routing.Internal.DefaultContentRoute.RouteSegmentContext(SegmentContext segmentContext)
   at EPiServer.Web.Routing.Internal.DefaultContentRoute.GetRouteData(HttpContextBase httpContext)
   at System.Web.Routing.RouteCollection.GetRouteData(HttpContextBase httpContext)
   at System.Web.Routing.UrlRoutingModule.PostResolveRequestCache(HttpContextBase context)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)",

It look like no code in Forms invoke in your exception. Could you try with a new simple Form to see if the problem still there?

That stack trace may have been a red herring. However your idea of setting up a simple form helped. Thanks

I've discovered that the issue is because of an overidden FormContainer view. If I remove that from the project (or rename the ElementBlocks views folder) the redirection functionality starts working again!

Any ideas what could cause this? What could be removed changed in FormsContainer.ascx that could cause this?

This exact thing (View html changes breaking core functionality) is one of my main frutrations with the Forms solution. There is a lot of logic within the views (the FormContainer.ascx) is complex. Styling / markup class changes are a definite implemetation requirement, but changing them can often break other functioinality. I'm never sure what class names / form params are needed etc. It makes the whole thing a little fragile and absolutely not a great developer experience :(

There are some hidden fields which rendered by FormContainerBlock.ascx, could you check those are still there in your custom view

<input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormGuid" value="<%: Model.Form.FormGuid %>" data-f-type="hidden" />
<input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormHostedPage" value="<%: FormsExtensions.GetCurrentPageLink().ToString() %>" data-f-type="hidden" />
<input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormLanguage" value="<%: FormsExtensions.GetCurrentPageLanguage() %>" data-f-type="hidden" />
<input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormCurrentStepIndex" value="<%: ViewBag.CurrentStepIndex ?? "" %>" data-f-type="hidden" />
<input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormSubmissionId" value="<%: ViewBag.FormSubmissionId %>" data-f-type="hidden" />

Ok, so the above hint set me on the right path and I've got to the bottom of this. 

First step was to remove our custom FormContainerBlock.ascx and fall back to the default. When submitting data using the default FormContainer the redirection querystrings from our custom were included in the redirection url.

Next I checked the difference in the post requests that were generated by each of the form submissions (one using our custom FormContainerBlock and one using the default). There was a singular difference/.

The following form value was missing from form submissions from our custom FormContainerBlock

--

Content-Disposition: form-data; name="submit"

1419ed9c-2c75-400a-8b40-a81969b64fee

--

Looking at the form elements I could see that this is the GUID that is set on the html button element that acts as the submit button for the form. Including this value in the form submission caused the redirection paremeters to be added.

I guess Episerver forms must use this submitted value to check if any of the parameters on the button should be used - such as finalising form, a specific redirect etc. 

THE ROOT CAUSE

Well if you've made it this far, then the root cause was a piece of custom javascript we put in to prevent double submission of form data. We hooked into the button click event and disbaled the button. All good, apart from disabled form element values aren't included by the browser in form submissions (hence themissing submit value).

The fix was to modify the submitbuttonelementblock and include an additional hidden form element with the form name of submit and a value of the guid, meaning that the relevant data is always submitted regardless of the state of the actual submit button.