Fix for requireJS loading issues (for ad blockers)

[Yonn-Trimoreau]

Please read #12828

Description

When uBlock (or any ad blocker) 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.

This fix catches the RequireJS script loading error, displays it in the console as is and returns true, to avoid execution flow to be broken.

Fixed Issues (if relevant)

1. Uncaught Error: Script error for: trackingCode error on every frontend page #12828: Uncaught Error: Script error for: trackingCode error on every frontend page

Manual testing scenarios

1. Install and enable uBlock Origin [Chrome/Firefox extension] on any stock Magento 2.2.2 installation
2. Open JS console, watch the issue raised (on any page)
3. Pass an order
4. Without my fix checkout would not work, since JS execution flow was broken by RequireJS script loading error

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

PS: could not provide unit/integration tests since it's raised by a browser extension

[orlangur]

Is it a common practice in Magento code to call console like console.error(error); or maybe there is some wrapper so that console is spoiled in dev mode only?

[Yonn-Trimoreau]

It seems there's a consoleLogger yes, let me fix this code style issue and integrate with the existing consoleLogger.

[omiroshnichenko]

Hi, @Yonn-Trimoreau. I agree with @orlangur that we must use wrapper, but unfortunately it's located in UI module and we can't depend on modules from lib/web. So you can revert your code to previous commit and fix code style(you have extra whitespaces on line before return).

[orlangur]

@omiroshnichenko, I've quickly grepped following code snippet

if (window.console && !this.element.is(this.options.defaultContainer) && $.mage.isDevMode(undefined)) {
                console.warn('This widget is intended to be attached to the body, not below.');
            }

should $.mage.isDevMode be utilized here or initial implementation is just fine?

[Yonn-Trimoreau]

@omiroshnichenko Done
@orlangur I will add it if @omiroshnichenko validates your idea

[omiroshnichenko]

@orlangur I also found this code snippet, but I can't found place where isDevMode widget initialized. Also, consoleLogger doesn't take into account current mode.

[Yonn-Trimoreau]

@orlangur @omiroshnichenko Since this bit of code will apply to all required scripts (through data-mage-init exclusively), it may be interesting for production debugging purposes if we leave the error displayed in the console even if devMode is disabled.

Maybe using console.warn(error); when in production mode could be less "alarming" but still allow debugging easily.

[omiroshnichenko]

@Yonn-Trimoreau Currently, we cannot get current mode in JS. So use console.error.

[Yonn-Trimoreau]

@omiroshnichenko I still would like to add a check on window.console.error, as I could see in swagger-ui.js at line 21987 [if ('console' in window && typeof window.console.warn === 'function') {]. Then current PR is ok to merge after Travis has ended his job.

[spectravp]

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