[confirmed] forwardpage.tpl JS redirect bug

[Eduardo G.]

===========DESCRIPTION===========

forwardpage.tpl includes sone jquery code to auto submit gateway form.

This code may not work because of misplaced html tag

 

=========STEPS TO REPLICATE=========

Using an offline payment gateway, whmcs shows the "please wait while you are redirected to the gateway you chose to make payment" message forever.

Note: This bug comes *only* when gateway module doesn't return a form.

When gateway payment returns with a "form" element in it, this will populate {$code} variable in template, and autoforward will work.

The problem comes when offline payment gateways don't return a "form" element

 

=======ADDITIONAL INFORMATION======

Original code inside forwardpage.tpl says:

<div id="submitfrm" class="textcenter">{$code}</div>
<form method="post" action="{if $invoiceid}viewinvoice.php?id={$invoiceid}{else}clientarea.php{/if}"></form>

 

As you see, there is a div with ID="submitfrm" which auto-closes, and after that, there is a "form" element which is out of the previous "div"

 

Then comes javacript:

setTimeout ( "autoForward()" , 5000 );
function autoForward() {
   var submitForm = $("#submitfrm").find("form");
   submitForm.submit();
}

 

Here jquery uses .find() method to find a "form" element *inside* $("#submitfrm") selector.

.find( selector )

Description: Get the descendants of each element in the current set of matched elements, filtered by a selector, jQuery object, or element.

 

That means that "<form>" should be inside "<div id="submitfrm">.

jQuery's description says it will look for that element *in the descendants* of each element, so it will look for "form" element as a descendant of the "div" element.

 

So, for this code to work, form element should be inside div element, like this:

<div id="submitfrm" class="textcenter">
{$code}
<form method="post" action="{if $invoiceid}viewinvoice.php?id={$invoiceid}{else}clientarea.php{/if}"></form>
</div>

[WHMCS Nate]

Hello,

 

Thanks for this report. It was previous noticed internally and was given case number of 4840. When the fix for this is released you should see that mentioned in our changelog.

 

Have a great day,

 

Nate C