Uncaught Error: Script error for: trackingCode error on every frontend page

[ghost]

Preconditions

1. Installed Magento version 2.2.2 with sample data.
2. checked in developer and production both mode.
3. Dotdigitalgroup_Email module is enabled downloaded with Magento version 2.2.2.

Steps to reproduce

1. Open Magento home page.
2. checked browser console and getting error Uncaught Error: Script error for: trackingCode .
   
3. Also, this error prevents to load custom UI component grid at frontend as shown in the screenshot-
   

Expected result

1. No error should occur.

Actual result

1. for every frontend page, checked browser console and getting error Uncaught Error: Script error for: trackingCode .
2. Also, this error prevents to load custom UI component grid at frontend.

[magento-engcom-team]

@poojawebkul , thank you for your report.
We were not able to reproduce this issue by following the steps you provided. Please provide more detailed steps to reproduce or try to reproduce this issue on a clean installation without any extentions.

[ghost]

@magento-engcom-team issue is updated please check.

[Yonn-Trimoreau]

uBlock Origin extension is the source of the issue.

It blocks the trackingCode.js file before it has the time to track you down. And that seems to be justified.

Here is the content of trackingCode.js :

define(['domReady!'], function () {
    'use strict';

    /**
     * Create script tag
     */
    function createTag() {
        var connector = document.createElement('script'),
            s = document.getElementsByTagName('script')[0];

        connector.type = 'text/javascript';
        connector.src =
            (document.location.protocol === 'https:' ? 'https://' : 'http://') + 't.trackedlink.net/_dmpt.js';
        s.parentNode.insertBefore(connector, s);
    }

    /**
     * Export/return tracking code init
     * @param {Object} trackingCode
     */
    return function (trackingCode) {
        if (trackingCode.isEnabled) {
            createTag();
        }
    };
});

And where does that lead to ? ==> A tracking script.. http://t.trackedlink.net/_dmpt.js

I cannot judge Magento team for recently integrating several external services into the Magento core (thinking of Shopial_Facebook & Dotdigitalgroup_Email). They may have some well justified commercial reasons.

But at least, it shouldn't break other functionalities if we're trying to protect our own privacy. For instance:

loading custom UI component grid at frontend

The solution may be here: https://stackoverflow.com/a/27626398/2110948

[bmxmale]

This file isn't minified during static-content:deployment this is reasone why on our site getting 404.

[hubertus2017]

We had the same problem also with uBlock. After deactivating dotmailer extension checkout works again.

[magento-engcom-team]

@poojawebkul , thanks for your update.
We were not able to reproduce this issue, please check this issue on vanilla installation.

[Yonn-Trimoreau]

Please read the replies @magento-engcom-team

The issue is with uBlock, and may [will certainly] happen when real life customers will visit our Magento site with uBlock activated.

When uBlock forbids trackingCode.js file from loading, the exception thrown by RequireJS breaks the JS execution flow, causing unexpected and random issues elsewhere on the website.

You shall fix this issue by catching the RequireJS exception when trackingCode.js fails to load and (maybe) display a more friendly message in the JS console.

Doing this, the JS execution flow would not be broken whenever a customer uses uBlock.

Some example of such a catch block can be found here

[ghost]

@magento-engcom-team Actually issue is only coming when uBlock is activated (as shown in the screenshot), otherwise, no error is coming.

[magento-engcom-team]

@poojawebkul, thank you for your report.
This seems to be correct Magento behavior. Please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this.
Otherwise you may submit Pull Request with the suggested changes.

[lingwooc]

@magento-engcom-team it seems to me that magento's checkout shouldn't fail because non essential js won't load. That's a simply horrible thing to describe as "correct Magento behavior". The checkout in particular should be made as resilient as possible.

@Yonn-Trimoreau gives a solution, perhaps you should consider implementing it for all non essential core js instead of shrugging it off.

Responses like this really make me fear for the direction of this project.

[vishalpatel14]

Hello Team,

Having same issue with one more error.

[2017-12-27 12:13:20] main.CRITICAL: Unable to resolve the source file for 'frontend/Vishal/base/en_US/trackingCode.js' [] []
[2017-12-27 12:13:21] main.CRITICAL: Unable to resolve the source file for 'frontend/Vishal/base/en_US/temandoCheckoutFieldsDefinition.js' [] []

Please let us know what is the solution?

[Brhmts]

Hello,
I just got this problem , after upgrade from version 2.2.1 to 2.2.2

I upgraded with composer , With no errors

i hope to find a solution

[kelsonzhao]

Hi,
I also got this problem, is there a solution to this problem?

[hostep]

Running into the same issue over here after upgrading to version 2.2.2. Disabling uBlock Origin fixes the problem, yet that's not the correct solution.

@magento-engcom-team: if a user chooses to install an ad/tracking blocker in his/her browser to avoid being tracked by a million different services and wants to make a website load faster because of not loading in megabytes of unnecessary javascript code, then the website should keep working properly. A website shouldn't stop working just because a user chooses to block certain non-essential scripts which tracks his/her behaviour.

In this case, blocking trackingCode.js - which from the looks of it is not really essential for anything, except for loading in yet another external tracking script - makes for example the checkout of Magento completely unusable.

Please remove the non-issue label, it's incorrect.
The proposed solution from @Yonn-Trimoreau sounds like a good solution for this problem.

[tony-sar]

same issue with any ad blocker . it breaks the checkout process. I don't think any program should track user and store owners without their consent and their should be a way for this type of tracking to be turned off and it should be notified to store owners about them . i reinstalled 2.2.1 and i don't see this issue.
The more i spend working with magento on my current project , more i started to hate everything about it . unfortunately , i have put lots of time and money on this project which is my first and last using magento.

[lingwooc]

Another solution is to just disable the Dotdigitalgroup_Email module. Its just cruft anyway.

[adamlavery]

Disabling Dotdigitalgroup_Email isn't a solution where DotMailer integration is required. All tracking modules must fail gracefully and without further impact where end-users have implemented tools to block tracking.

The secondary concern here is why is Magento core including 3rd party integrations that are installed enabled by default? It's fine to include these common integrations as standard, but they should be disabled until the site owner decides to use them.

[vishalpatel14]

Still same issue and there is no solution.

[Yonn-Trimoreau]

Here is a solution that works for all JS files required through data-mage-init:

In your theme, create the file: design/frontend/<Vendor>/<theme>/web/mage/apply/main.js

Copy & paste contents from: vendor/magento/magento2-base/lib/web/mage/apply/main.js

Add a third parameter to the require function call inside the init function:

function(error) {
    console.error(error);
    return true;
}

As an example, for Magento 2.2.2, you should replace this:

function init(el, config, component) {
    require([component], function (fn) {

        if (typeof fn === 'object') {
            fn = fn[component].bind(fn);
        }

        if (_.isFunction(fn)) {
            fn(config, el);
        } else if ($(el)[component]) {
            $(el)[component](config);
        }
    });
}

By this:

function init(el, config, component) {
    require([component], function (fn) {

        if (typeof fn === 'object') {
            fn = fn[component].bind(fn);
        }

        if (_.isFunction(fn)) {
            fn(config, el);
        } else if ($(el)[component]) {
            $(el)[component](config);
        }
    }, function(error) {
        console.warn('Some JS file failed to load, maybe because of an ad-blocker');
        console.warn(error);
        return true;
    });
}

Remove the folder var/view_preprocessed, remove the file (or symlink) pub/static/frontend/<Vendor>/<theme>/<language_LANGUAGE>/mage/apply/main.js, reload the page.

You should now see in your JS console that the error thrown by requireJS is replaced by a warning instead of a fatal error breaking the JS execution flow.

Beware that it will catch all requireJS loading errors made through data-mage-init. I can't find any issues that could be created by doing this, but it could be misleading to change an error to a warning since the developers may not understand this as an important fact.

I would personally replace console.warn(error); by console.error(error); when I checked the fix effectively works to avoid underestimating the console message.

[hostep]

@Yonn-Trimoreau: sounds like a good solution.

Any chance you could propose this in a Pull Request, I think the Magento devs will be able to give you faster feedback when creating a PR then they will in this issue, since they don't seem to think this is a real issue :p

[Yonn-Trimoreau]

Yes, I could.

But what's bothering me is that I found a solution only for scripts initiated using data-mage-init. Behavior won't be uniform across all required scripts. I would have preferred a "catch all" solution.

I'm still looking for enhancements, maybe here... It would be very interesting if a Magento core developer could come by this topic and give his opinion.

I'm still investigating and I will link my PR to this topic if I do so.

[Yonn-Trimoreau]

PR done.

I was thinking of a better solution but I don't have enough time to do it: http://mydons.com/error-handler-with-requirejs/

[orlangur]

Removing label for re-evaluation, for me personally this issue looks definitely as must-be-fixed.

[Yonn-Trimoreau]

Can you also remove the non-issue label on the PR please?

[magento-team]

Hi @poojawebkul. Thank you for your report.
The issue has been fixed in #13061 by @Yonn-Trimoreau in 2.2-develop branch
Related commit(s):

• 247fbea
• 23a946b
• 62b4b6d
• 7843395
• d826cb3

The fix will be available with the upcoming patch release.

[ghost]

Hello @magento-team, thanks for the notification.

[lingwooc]

I've implemented @Yonn-Trimoreau's fix. I'm still investigating, but my checkout breaks (checkout-loader is never hidden) when the google analytics script (from Magento_GoogleAnalytics) is blocked. I need to check with luma but on my theme disabling Magento_GoogleAnalytics or ublockorigin fixes the issue.

I've tried editing Magento_GoogleAnalytic\view\frontend\templates\ga.phtml to use "require(" directly instead of "x-magento-init" and it shows the same behaviour, even with the require error caught (the blocked GET error still seems to escape...)

Edit: ah just found #12428 describing the issue. #13061 does not fix this.

[Yonn-Trimoreau]

Have you remove the file pub/static/frontend/<Vendor>/<theme>/<language_LANGUAGE>/mage/apply/main.js? If not, you may be still loading the old Magento file. Open your network tab and check if you're loading your overriden main.js.

If it still does not work and you want to try using require instead of x-magento-init, you can catch the script loading error by using something like this:

require([path], function(content){
  //need to catch errors as this will not be called;
}, function (err) {
  //display error to user
});

I have not tried my fix against Google Analytics script loading error.

[lingwooc]

@Yonn-Trimoreau you've probably seen in the other issue but it's definitely loading the new js. I also tried require directly, bizarrely that doesn't work either. I'm just going to block the script on the effected pages of the checkout (maybe them all!)

[sammarcus]

Not to derail this too much, but I don't think dotmailer has any business being included by default.

I cannot judge Magento team for recently integrating several external services into the Magento core (thinking of Shopial_Facebook & Dotdigitalgroup_Email). They may have some well justified commercial reasons.

I am judging them for force-adding a third party service that they are almost certainly getting payment for, only for it to break core functionality for a large subset of users. If they insist on including dotmailer, it should have been disabled by default. That it broke core functionality when using tracker blockers elevates this issue from nuisance to a serious lapse in judgement. Isn't that the purpose of Magento's extensibility, so site owners can pick and choose what external fee-based services they'd like to utilize?

[magento-engcom-team]

Hi @poojawebkul. Thank you for your report.
The issue has been fixed in magento-engcom/magento2ce#1342 by @magento-engcom-team in 2.3-develop branch
Related commit(s):

• aa93f83
• 0b76fcd
• be77fdd
• 4bad8be
• 59e1020
• ef63b3a
• a278aaf
• f7c00d7
• f1ecb11
• 74aabb4
• 1d66e5e
• dc4977d
• 99f982c
• 76c4f0d
• 9e2cc5e
• 82d488b

The fix will be available with the upcoming 2.3.0 release.

[lingwooc]

This needs backporting to 2.2.x. Along with all the fixes for similar issues.

[pravalitera]

@lingwooc Welcome to Magento 2 World, a world that maintains 3 branches, 2.0, 2.1 and 2.2, and you dont't know why when you understand how many bugs are corrected in 2.2, and not in 2.1, in 2.1 and not in 2.0. And when they close tickets saying "solved in 2.3". And you just want to slap everyone.

[Yonn-Trimoreau]

Hopefully you can backport this yourself by making your own module (this fix is not too hard.. and I explained how to do it in your own module before).. Or you could update to latest version.. Still, maintaining 3 branches at a time seems like a whole lot of mess..

[lingwooc]

It is at least tagged as being fixed in 2.2.x now. I do wonder how many sites can't/couldnt sell to people with and blockers and they don't even know!

Sadly having three branches isn't the worst of the mess :( and this is just the result of disgracefully crap testing

[pravalitera]

@lingwooc The big problem is that it seems some tickets are noted "Fixed in 2.2.x", and when you check merges, it is not true... I don't know for this particular bug, but i saw many threads where people are asking question such as "I can't find it in 2.2.x, am i wrong ? " with no further response...

[lingwooc]

@pravalitera oh...well...what can you say? At least we aren't paying them for it.

[wescey]

Have an M2.2 installation and problem exists if using ad/tracking blocker on Safari.

[spectravp]

I have this issue with Magento 2.2.3. It's great that is appears resolved in the 2.3 branch, but it is now more than 2 months since that post and 2.3 isn't released.

[spectravp]

This fix does not work; manually applied it to 2.2.3, Safari 11.1, Mac High Sierra

Enabling JS Bundling solved the problem for me.

[simon-letch]

This pull request solves the root cause of the issue: #14874

History states it was fixed in 2.2.5, but I only see the changes in 2.2.6+.

[pratikhmehta]

This is the actual solution and it works for me.

Please check this link #13346 (comment)

Thanks