-
Notifications
You must be signed in to change notification settings - Fork 57
Block UI during onApprove callback (4712) #3533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
764a49f to
2937d6a
Compare
Narek13
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for working on this.
570f8fa to
ba2b724
Compare
Test using WordPress PlaygroundThe changes in this pull request can be previewed and tested using a WordPress Playground instance. 🔗 Test this pull request with WordPress Playground What's included:
Login credentials:
Plugin Details:
🤖 Auto-generated for commit b267836 • Last updated: 2025-09-03T21:29:56.465Z |
Narek13
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this. LGTM
ba2b724 to
02d05dc
Compare
da9f409 to
d4a3b6d
Compare
d4a3b6d to
c7270c8
Compare
Clean AppSwitch hash params on Pay for Order page (5031)
When returning from AppSwitch, the
onApprovecallback takes a few seconds to finish processing. During this time, the user could click the PayPal button again or trigger other WooCommerce actions like "Proceed to Checkout", which disrupted the AppSwitch flow and caused unexpected issues reported by QA.This PR addresses the problem by implementing the same approach used at checkout: blocking the entire UI while the payment is being processed.
Classic contexts:
To address this in classic contexts, I've reused the
Spinnerclass, triggering a full-page blocking overlay when the onApprove callback is triggered, and removing it in the.finallycallback.Block contexts:
Block contexts are trickier. Unblocking the spinner in the
.finallycallback of theonApprovemethod was too soon, since WooCommerce has its own async order processing in block contexts. This left a significant time window in which the user could perform actions like clicking "Proceed to Checkout".To handle block contexts, I’ve set up a useEffect that tracks the value of
isFullPageSpinnerActiveand toggles the spinner when it changes. This allows the spinner to be enabled in the onApprove callback, remain active, and be removed only in exceptional circumstances such as checkout errors which are handled by WooCommerce events.