trackingCode.js blocked by Adblock Plus in checkout shipping step

[thomas-kl1]

Can't finalize order, checkout blocked due to script filename

Preconditions

1. Magento 2.2.2, with or without sample data
2. Chrome extension adblock plus installed

Steps to reproduce

1. Add a product to cart
2. Go to the cart
3. Process to checkout

Expected result

1. Complete shipping and payment steps

Actual result

1. Step shipping with infinite loading, the following error appear in web client console:
   
   

Final customers who have the adblock plus extension can't pass orders, I think they should have an alert message or the script should be renamed.

Suggestion

Every files blocked by an ad blocker shouldn't broke the core functionality (the files blocked are trackers, and does not impact the end user experience).

EDIT:
same potential issues:
#12828
#12428

[thomas-kl1]

It seems to be related to #12828

[orlangur]

@thomas-blackbird this is actually a duplicate of #12828.

Could you please check if the issue persists on 2.2-develop? It was fixed recently and not released yet, until then you can apply changes from mentioned commits to your instance manually.

[thomas-kl1]

I have applied the changes in local (of this PR: https://github.com/magento/magento2/pull/13061/files), but it doesn't change anything...
There's still the "wheel of horror" and the error above. I'll try with 2.2-developer later.

[orlangur]

@thomas-blackbird try setting breakpoint in lib/web/mage/apply/main.js at corresponding line in incognito mode. It has not chance to not work (or at least there should be another error displayed).

[thomas-kl1]

I confirm that it do not block the other loads, however, (it seems to be specific for the checkout page, regarding the issue #12828 ), the loader is not ended and we can't continue.

My trace log, with the modification of the PR:

result in console log:

(above, script blocked by AdBlock Plus)

Actual result (everything is loaded fine, but the loader is not removed):

[thomas-kl1]

It seems to be the same issue as #12428

[lingwooc]

@thomas-blackbird Check you have the fix from the PR #13061 if so try a similar fix using JQuery to attempt a preload before letting require spray fail everywhere.

I can't make head nor tail of this mess. I just disabled the dot mailer crapware (you may not have the luxury) and applied my GA fix in my theme. Whoever designed this checkout is...not very good. Whoever does the testing is....also not very good. It's way too brittle.

[thomas-kl1]

@lingwooc actually I have applied the fix of #13061 and it prevent to fail the load of the others scripts. However, and it seems specific to the checkout page, the loader widget don't stop, and so, the customer can't pass an order, which is a critical bug. (If he has an ad blocker of course, uBlock or adBlock Plus)

[lingwooc]

@thomas-blackbird I thought you probably had. Hmmm, if my jquery approach doesn't help and you can't disable dot mailer then I'm out of ideas.

I agree, that this is a critical issue. There have been assumptions in the design of this checkout (namely that everything will load) that clearly aren't true. The worst thing is that magento2.2.2 has been broken out of the box for commercial reasons.

[thomas-kl1]

Well I don't know a lot about how requireJS is implemented in Magento, but it seems that the checkout loader Magento/Checkout/view/frontend/web/js/checkout-loader.js can't call the method hideLoader.
Indeed in the method init the method hideLoader is passed as a callback to the magento requiredJS resolver, defined at: lib/mage/requirejs/resolver.js. Actually the checkout loader subscribe the end of the loader to the condition that all dependencies has been loaded (it's fair and logic).

What I've understood: the resolver is still in pending state because a dependence has not been loaded (trackingCode in our case).
I don't know how it should be fixed and I'm not enough good to help, but I think that a level should exist and determine if a dependency is require or can be ignored if it failed while resolving.

[magento-engcom-team]

@thomas-blackbird, thank you for your report.
We've acknowledged the issue and added to our backlog.