JS error in console on checkout when recaptcha for checkout/placing order is not enabled

basvanpoppel commented 3 years ago

Preconditions (*)

Magento 2.4.3
'Stores > Configuration > Security > Google reCAPTCHA Storefront > Storefront > Enable for Checkout/Placing Order' set to 'No' (that's the default config)

Steps to reproduce (*)

Add a product to cart
Go to checkout
Open element inspector, see the JS error

Expected result (*)

No JS errors on checkout
Besides not wanting to run into errors, I wouldn't expect checkout to load any recaptcha JS when all the recaptcha options are not enabled.

Actual result (*)

Error message from recaptcha JS:

knockout.js:3753 Uncaught TypeError: Unable to process binding "afterRender: function(){return renderReCaptcha() }"
Message: Cannot read property 'rendering' of undefined
at UiClass.initCaptcha (reCaptcha.js:117)
at UiClass.renderReCaptcha (reCaptcha.js:182)
at afterRender (eval at createBindingsStringEvaluator (knockout.js:3221), <anonymous>:3:134)
at init (after-render.js:17)
at knockout.js:3730
at Object.ignore (knockout.js:1563)
at knockout.js:3729
at Object.arrayForEach (knockout.js:168)
at applyBindingsToNodeInternal (knockout.js:3715)
at applyBindingsToNodeAndDescendantsInternal (knockout.js:3573)

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

[ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
[ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
[ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
[x] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
[ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

ps. I think severity should be higher, because any dev working om checkout will spot this, and will be looking for a fix. (I first checked all of my modules, themes and 3rd party modules: it's time consuming.)

m2-assistant[bot] commented 3 years ago

Hi @basvanpoppel. Thank you for your report. To help us process this issue please make sure that you provided the following information:

Summary of the issue
Information on your environment
Steps to reproduce
Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

Join Magento Community Engineering Slack and ask your questions in #github channel.

:warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

mrtuvn commented 3 years ago

Can you proceed checkout with this js error?

mrtuvn commented 3 years ago

Not actually blocker but turn out even you not enable settings (Set NO) but code base still check it by default

onlinebizsoft commented 3 years ago

bug reported too fast :)

magento-engcom-team commented 3 years ago

:white_check_mark: Confirmed by @mrtuvn Thank you for verifying the issue. Based on the provided information internal tickets MC-43053 were created

Issue Available: @mrtuvn, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

mrtuvn commented 3 years ago

Hi @basvanpoppel Is P3 priority correct for such case ?

mrtuvn commented 3 years ago

Component: Recaptcha

basvanpoppel commented 3 years ago

Hi @mrtuvn I would give it P2: Checkout doesn't break (the recaptcha component isn't used, so the JS error doesn't actually hurt) it's not critical and no work-around is needed, which follows P3 description.

But this is awful for developers working on checkout: I have several custom ui components, layout processors and mixins on any checkout i work on. If there's an issue after upgrading, I will first look at my customisations, then at third party modules, then Magento.

Imagine every dev going through this process after seeing this issue, that's a lot of wasted time - and a lot of unhappy devs.

basvanpoppel commented 3 years ago

I'm working on a PR for this.

chequille commented 3 years ago

New version new bug. I would sugest to set it P1 or better P -100 !?!?!?!?! Facing the same probllem and it is ugly to have errors even if they do not break the checkout process.

My opinion Chequille

speedupmate commented 3 years ago

In addition to this:

adds a global place order mixin . what this does is that even if functionality is not configured , mixins are added in all cases see : https://github.com/magento/magento2/issues/15967
mixin has a hardcoded dependency to Magento_ReCaptchaWebapiUi not mentioned in module.xml that extension itself adds a mixin to jquery .o0 see: https://github.com/magento/magento2/issues/15967
adds a afterRender call to template forcing to init this functionality even if not configured or needed or each time the template is rendered , bad practice and hard UI dependency

speedupmate commented 3 years ago

Hi @mrtuvn I would give it P2: Checkout doesn't break (the recaptcha component isn't used, so the JS error doesn't actually hurt) it's not critical and no work-around is needed, which follows P3 description.

@basvanpoppel ? install a clean instance of m2 you can't checkout cause of those issues without reCaptcha configuration being enabled and valid means Magento2 does not work out of the box.

By default if extension is in system and is not configured to be used should mean no assets are included in storefront at all. Aim for this in your PR, thanks.

dudzio12 commented 3 years ago

Fix for the impatient (Magento composer installations).

@basvanpoppel -this implements your suggested PR (https://github.com/magento/security-package/pull/302) changes :)

/patches/composer/github-issue-33741.diff

diff --git a/Block/LayoutProcessor/Checkout/Onepage.php b/Block/LayoutProcessor/Checkout/Onepage.php
index 390bf712..b2d5b777 100644
--- a/Block/LayoutProcessor/Checkout/Onepage.php
+++ b/Block/LayoutProcessor/Checkout/Onepage.php
@@ -79,7 +79,8 @@ class Onepage implements LayoutProcessorInterface
             ['place-order-recaptcha']['settings'] = $this->captchaUiConfigResolver->get($key);
         } else {
             if (isset($jsLayout['components']['checkout']['children']['steps']['children']['billing-step']['children']
-                ['payment']['children']['beforeMethods']['children']['place-order-recaptcha'])) {
+                ['payment']['children']['beforeMethods']['children']['place-order-recaptcha-container']['children']
+                ['place-order-recaptcha'])) {
                 unset($jsLayout['components']['checkout']['children']['steps']['children']['billing-step']['children']
                     ['payment']['children']['beforeMethods']['children']['place-order-recaptcha-container']
                     ['children']['place-order-recaptcha']);
@@ -89,3 +90,4 @@ class Onepage implements LayoutProcessorInterface
         return $jsLayout;
     }
 }
+

/composer.json

{
(...)
    "extra": {
        (...)
        "patches": {
            (...)
            "magento/module-re-captcha-checkout": {
                "Fixed checkout reCaptcha disabling #33741": "patches/composer/github-issue-33741.diff"
            }
        }
    }
}

speedupmate commented 3 years ago

@basvanpoppel @dudzio12 although good effort it does not free you from all the loaded reCaptcha mixins defined in following files, those will still wrap what they wrap enabled/disabled layout nodes included or not

vendor/magento/module-re-captcha-paypal/view/frontend/requirejs-config.js 
vendor/magento/module-re-captcha-webapi-ui/view/frontend/requirejs-config.js
vendor/magento/module-re-captcha-frontend-ui/view/frontend/requirejs-config.js
vendor/magento/module-re-captcha-checkout/view/frontend/requirejs-config.js

it mostly means that even if recaptchas are not used your default behaviour is wrapped and no other module tests for those wrapped conditions and mostly assume that defaults are used

dudzio12 commented 3 years ago

@basvanpoppel That's understandable of course, I needed patch to kickstart my project's upgrades, so it is what it is.

I'm still looking forward for you to complete the PR :)

Then I will prepare another patch to fix the issue.

@mrtuvn What is the politics on P2 bug fixes? It will be released as separate patch, next patch release -p1 or in the next minor release?

mrtuvn commented 3 years ago

p2 label is lower priority than p1/p0. It's depend on specific case of ticket. It's not related with fix order deliver to next release. i'm not sure magento team will deliver this fixes as patch (seperate) or regular fix as normal. I saw a pull request related in the case owner disabled captcha from backend but captcha js files still request from server. But we already have PR for that here Put here for anyone interesting https://github.com/magento/magento2/pull/33200. In this specific issue imho captcha js should only available if user put both user/key pair value in backend

basvanpoppel commented 3 years ago

@mrtuvn this issue still has 'ready for dev' status, while this pr should be in the review process, I think: https://github.com/magento/security-package/pull/302

@speedupmate This PR just fixes this specific issue. Preventing other modules from adding wrappers isn't my goal here. If you know of a better way to fix this issue, please share it.

speedupmate commented 3 years ago

@speedupmate This PR just fixes this specific issue. Preventing other modules from adding wrappers isn't my goal here. If you know of a better way to fix this issue, please share it.

Part of this is the layoutprocessor style config you are trying to add but with a plugin to requirejs-config collection class to just exclude non-configured extension files on matching conditions (like enabled/disabled , auth failing etc).

Even better would be stopping popularising mixins as a main go to weapon in devdocs for editing/wrapping component functionality as this is really a sledgehammer that affects wider scope than usual extension tries to cover.

basvanpoppel commented 3 years ago

@speedupmate I think you haven't seen the PR, as I'm not adding config - i fixed a missing part in what's already there.

For the rest I totally agree with you.

Hanhan1989 commented 3 years ago

I am waiting for this fix. When it will be fixed ? What can I do in the meantime?

mrtuvn commented 3 years ago

The fix already mentioned above links

Hanhan1989 commented 3 years ago

The fix already mentioned above links

thanks

chittima commented 2 years ago

Looks like issue is already fixed. The issue is not reproducible on the latest 2.4-develop

hostep commented 2 years ago

@chittima: could you leave some more detailed info please? Like providing commits that fixed this. Just closing an issue with so little explanation is a bit rude ... Also: have you tested this while magento/security-package was installed? The comments above seem to indicate that the bug is part of that package.

sdzhepa commented 2 years ago

Hello @hostep @mrtuvn @glevhen

Let me try to shade more lite on the issue based on communication and collaboration in the internal Jira ticket.

recently Jira ticket related to this public report was taken into the sprint scope by one of the internal teams
But on the initial phase, a QA engineer was not able to reproduce this issue on the latest 2.4-develop branch with security-package installed
also issue cannot be reproduced on the 2.4.3-p1

Based on such verification, the ticket was closed by QA with the resolution "cannot reproduce" - according to workflow. It looks like the problem was already fixed in the scope of some other PRs/commits/tasks etc.

If you still experience a similar issue on the latest version of code I would recommend opening a new issue with updated versions/steps and actual/expected results

chequille commented 2 years ago

Unbelievable !!!! we need the information what is finally be done to fix this issue. We do not want to wait till 2.4.3-p1 is out as it could take a few weeks/months till it is released.

hostep commented 2 years ago

It's actually pretty close, the release of 2.4.3-p1 😉

Thanks @sdzhepa for the extra info, however it would still be nice if somebody could figure out how it got fixed.

lytesaber commented 2 years ago

Just updated from 2.4.3 to 2.4.3-p1 and still experiencing this error in checkout unless reCAPTCHA is configured.

Errors being thrown due to optional configuration not being configured wastes a lot of time. As covered above when updating between versions going through a smashing any log exceptions or console errors thrown post upgrade is standard process and this error in checkout is just another distraction and another pointless issue to investigate. I don't know why errors are seen as acceptable, when the goal should be 0 errors and warnings.

Is there actually going to be a fix put in place for this?

engcom-November commented 2 years ago

Verified this issue on Magento 2.4-develop and 2.4.3 versions and the issue is not reproducible on 2.4-develop branch but is reproducible on 2.4.3 version:

sdzhepa commented 2 years ago

@engcom-November Could you please check it on the 2.4.3-p1 release? (it is the lates release)

sdzhepa commented 2 years ago

https://github.com/magento/security-package/pull/302

engcom-November commented 2 years ago

Verified the issue on 2.4.3-p1 version as well and the issue is reproducible:

nicholasscottfish commented 2 years ago

@engcom-November

Do we expect a patch to be released soon?

nathanjosiah commented 2 years ago

Fix merged in https://github.com/magento-commerce/security-package/pull/54 (https://github.com/magento/security-package/pull/302)

Kerlitek commented 2 years ago

Just a link for those looking for the actual SOLUTION https://github.com/magento/security-package/pull/302/commits/d25432de3b33946b88e93ddcfd01f5e898510a15

jesperingels commented 2 years ago

For anyone looking for a patch on Magento v2.4.3-p1

github-issue-33741.patch

diff --git a/vendor/magento/module-re-captcha-checkout/Block/LayoutProcessor/Checkout/Onepage.php b/vendor/magento/module-re-captcha-checkout/Block/LayoutProcessor/Checkout/Onepage.php
index 3ee2rd..8349152 111644
--- a/vendor/magento/module-re-captcha-checkout/Block/LayoutProcessor/Checkout/Onepage.php
+++ b/vendor/magento/module-re-captcha-checkout/Block/LayoutProcessor/Checkout/Onepage.php
@@ -79,7 +79,8 @@
             ['place-order-recaptcha']['settings'] = $this->captchaUiConfigResolver->get($key);
         } else {
             if (isset($jsLayout['components']['checkout']['children']['steps']['children']['billing-step']['children']
-                ['payment']['children']['beforeMethods']['children']['place-order-recaptcha'])) {
+                ['payment']['children']['beforeMethods']['children']['place-order-recaptcha-container']['children']
+                ['place-order-recaptcha'])) {
                 unset($jsLayout['components']['checkout']['children']['steps']['children']['billing-step']['children']
                     ['payment']['children']['beforeMethods']['children']['place-order-recaptcha-container']
                     ['children']['place-order-recaptcha']);

erfanimani commented 2 years ago

I would have expected this to be released as a Magento Quality Patch, or is this issue too small for that?

Aquive commented 1 year ago

~I still have this issue on Magento 2.4.5~ It is solved in 2.4.5

magento / magento2