[Bug] matomo.js erroring on javaEnabled property

[terminatingcode]

What happened?

Errors started coming through on our end since Dec 9, 10:02 PM

Our Matomo.js script is erroring on accessing the javaEnabled property

Looking at the stats, all users initiating the error are on Chrome browser (125.0.6422, 126.0.6478, 127.0.6523) and Windows >10.

What should happen?

no error

How can this be reproduced?

n/a

Matomo version

matomo.js

PHP version

No response

Server operating system

No response

What browsers are you seeing the problem on?

Chrome

Computer operating system

No response

Relevant log output

'get' on proxy: property 'javaEnabled' is a read-only and non-configurable data property on the proxy target but the proxy did not return its actual value (expected 'function () {
            return false;
        }' but got 'function (...args) {

Validations

• Read our Contributing Guidelines.
• Follow our Security Policy.
• Check that there isn't already an issue that reports the same bug to avoid creating duplicates.
• The provided steps to reproduce is a minimal reproducible of the Bug.

[fattybenji]

Same problem here, also started appearing on december 9th around 10pm (CET)

A little bit more output:

'get' on proxy: property 'javaEnabled' is a read-only and non-configurable data property on the proxy target but the proxy did not return its actual value (expected 'function () {
            return false;
        }' but got 'function (...args) {
                return value.apply(target, args);
            }')

We're using version 5.1.1.

Update: we've noticed that all calls come from Microsoft IPs.

[Yhuley]

We have same problem.

All users who initiate the error use Chrome (125.0.6422, 127.0.6523) and Windows >10

[sgiehl]

I've tried to check that using browser stack, but can't see any error when visiting a page where the matomo tracker is integrated with older chrome versions on windows 10 or windows 11.
Is anyone of you maybe able to share a link to a site where that error occurs?

[david-bezero]

@sgiehl does the matomo code create a proxy around the navigator object at all?

If so, it seems this bug is caused by that proxy, which will need fixing here.

If not, it seems likely (from @fattybenji noting that this is limited to Microsoft IPs) that this is coming from (e.g.) a malware scanning service which is creating its own navigator proxy object, with the issue being triggered by matomo only because it attempts to access a property that they haven't set up correctly. Unfortunately Microsoft has form here and the common advice is to simply filter out the errors since they won't fix them.

In the latter case, one option matomo might want to consider is to simply not invoke (or even access) javaEnabled unless the browser is detected to be one where this might return a meaningful value (since it is deprecated and all modern browsers hard-code it to false anyway).

[david-bezero]

on your question about the call site, it is reported as matomo.js in c6 at line 40:841, which appears to be here in the unminified code:

matomo/js/piwik.js

Line 3422 in 20cfe2d

typeof navigator.javaEnabled !== 'unknown' &&

(specifically on the typeof navigator.javaEnabled check)

[sgiehl]

We are unable to reproduce that. Is anyone able to reproduce that manually or can anyone provide an URL where that happened?
Without a proper reproduction it's hard to say where the problem is and how to fix this.
It could in theory even be an automated crawler doing weird things 🤷

[david-bezero]

It could in theory even be an automated crawler doing weird things

I think this is the most likely explanation (see my first comment for details)

I'm not aware of this happening in a browser I have access to; just getting reports from the automated error handling.

The root cause is probably for Microsoft to fix, but I doubt they'll look at it. It would be nice if matomo updated this code to only check javaEnabled for browsers where it might be meaningful (which would fix this as a side-effect), especially since I imagine 99.9% of Matomo's users don't even care about the presence of Java on client machines!

The only other option is for every matomo user to add this to their list of ignored errors, to avoid noise from Microsoft's scans.

[sgiehl]

We could also add a try/catch around that block. But it's hard to test if that works as expected.
Only checking the flag based on the detected browser might also not work reliable if someone spoofs a different browser

[david-bezero]

FWIW there's already a browser check for Edge on that code, which would have a similar limitation with spoofing.

You can replicate the issue with this setup code, which may or may not be entirely representative of what Microsoft's environment is using:

Object.defineProperty(navigator, 'javaEnabled', {
  value: () => false,
  writeable: false,
  configurable: false,
});

Object.defineProperty(window, 'navigator', {
  value: new Proxy(window.navigator, {
    get(target, prop, receiver) {
      if (prop === 'javaEnabled') return () => false;
      return Reflect.get(target, prop, receiver);
    }
  }),
});

// now accessing navigator.javaEnabled throws the error from this thread

[ipecador]

If I correctly understand the code, the problematic code is within a block that excludes IE < 11 but does not call navigatorAlias because it does not exist under IE6/IE7. This (now) looks like useless code.

matomo/js/piwik.js

Line 3407 in 20cfe2d

if (!((new RegExp('MSIE')).test(navigatorAlias.userAgent))) {

matomo/js/piwik.js

Line 3419 in 20cfe2d

// IE6/IE7 navigator.javaEnabled can't be aliased, so test directly

It seems to me that the problematic line has no more reason to be there so deleting it may (slightly) lighten the code and fix this issue.

matomo/js/piwik.js

Line 3422 in 20cfe2d

typeof navigator.javaEnabled !== 'unknown' &&

[petergoes]

@sgiehl
I see this issue in pop up in our Sentry error tracking all the time.

One of the urls Sentry is reporting:
https://decorrespondent.nl/15760/de-slechtste-baas-is-de-baas-die-de-baas-wil-worden-en-meer-wetenschappelijke-inzichten-over-de-baas/c9a91565-2d3f-0e2b-085c-2187ea063d12

Other data from Sentry:

Hope this helps you

[sgiehl]

@petergoes I've tried your URL with all those Chrome versions using BrowserStack and none of them is throwing that JavaScript error for me. Are you maybe also able to see if all the traffic is coming from the same IP (range)?

[petergoes]

@sgiehl, I accumulated the multiple sentry issues regarding this issue and I can definitely say that there are multiple users (with different ip addresses) that experience this issue

see this screenshot, which tells me that we have 1.3K users experiencing this issue