Steps to reproduce:

- Configure a checkout page with payment methods pane, billing address pane or coupon pane. In theory the error should happen with other panes that sent AJAX requests.
- Select a payment method other than first default option.
- Interact with other pane that sent an AJAX request E.g. change country from addressfield.
- Submit the checkout page.
- Validation error for the first default option payment method avoid submission.

(Attached are screenshots to reproduce the error)

CommentFileSizeAuthor
#3 2028195.payment_method_selection.patch927 bytesrszrama
#1 commerce-payment_method_resetted_after_interact_ajax_pane_element-2028195.patch2.66 KBcitlacom
payment_method_devault_value_override3.png233.04 KBcitlacom
payment_method_devault_value_override2.png245.47 KBcitlacom
payment_method_devault_value_override1.png241.79 KBcitlacom

Comments

citlacom’s picture

citlacom commented
Status: Active » Needs review
StatusFileSize
new commerce-payment_method_resetted_after_interact_ajax_pane_element-2028195.patch2.66 KB

Here is the solution I suggest.

Status: Needs review » Needs work

The last submitted patch, commerce-payment_method_resetted_after_interact_ajax_pane_element-2028195.patch, failed testing.

rszrama’s picture

rszrama commented
Version: 7.x-1.4 » 7.x-1.x-dev
Status: Needs work » Needs review
StatusFileSize
new 2028195.payment_method_selection.patch927 bytes

I don't generally like to use $form_state['input'] if I can avoid it. We use #limit_validation_errors when the country select list is changed, and that means the value in $form_state['input'] may actually be a non-existent payment method. I'm not certain someone could use that to their advantage, but I'd rather not give 'em the chance; it doesn't appear our validate handler does any check to make sure the payment method value is an "allowed" value, for example.

The attached patch seems to address the problem, though, by first looking in the validated values array and if nothing is found looking to see if there is a payment method value in the input array. If so, we use the #default_value from the $form_state['complete form'], which at this point in time would be the last rendered selection. In testing, it appears to have solved the reported issue and doesn't seem to cause any regression.

rszrama’s picture

rszrama commented
Status: Needs review » Fixed

Committing that.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.