__internalEmitPaymentProcessingEvent not mapping shippingData property

[paymentplugins]

Describe the bug

In versions of WC Blocks prior to 9.5.0, the response object returned from the onPaymentProcessing event could include a shippingData property like the following:

{
    meta: {
        shippingData: {
            address: {...}
        }
    }
}

In versions 9.5.0 and greater, a new property called shippingAddress was added. In function __internalEmitPaymentProcessingEvent, there is code to handle the now deprecated shippingData property. The issue is, the deprecation code assumes the shippingData object is flat and thus ignores the child property shippingData.address. That means that when the validation function isShippingAddress is called, it returns false and the address object is not used to populate the checkout fields.

To reproduce

Steps to reproduce the behavior:

1. Install a WooCommerce version which includes WC Blocks 9.4.1
2. Install Payment Plugins for Stripe WooCommerce. Version must be less than 3.3.39
3. Add an item to the cart and navigate to the blocks checkout page
4. Choose an express payment method like Google Pay
5. When the Pay button is clicked, the email, first name, and last name fields, and street fields won't be populated

Expected behavior

WC Blocks should handle the response object for integrations that follow the design from versions < 9.5.0.

Additional context

On line 84 of /assets/js/data/payment/thunks.ts, the shippingData property is created by destructuring the response.meta object. However, this ignores that the shippingData contains a child property like shippingData.address that has the actual address.

On line 112 of /assets/js/data/payment/thunks.ts, if the variable shippingDataFromResponse exists, it overrides the shippingAddress variable.

On line 137 of /assets/js/data/payment/thunks.ts, if the shipping address is not valid, the setShippingAddress function is not called. The shippingAddress object will never be valid because the actual address object is nested within the shippingData object.

[mikejolley]

Thanks for pointing this out @paymentplugins. I can see the change happened in #8163

address was previously used from the shippingData object here: https://github.com/woocommerce/woocommerce-blocks/pull/8163/files#diff-e1ee9f69cb2267cbf39d788783a0a46c607756efcee1cbb91bd25d729c7999d4L84

@ralucaStan I'm not sure what we should do here. On the one hand this is a backwards compatibility break, but on the other this has been live for several releases now, including core releases, with seemingly low impact (as this is the first report of the issue).