This warning already existed for a long time with no changes in Matomo 4.9.0.

@CyrilBrulebois You should check if your browser blocks any requests to Matomo. That message is automatically hidden by CSS/JS. If it's visible that means the requests failed.

@sgiehl Thanks, I had been checking this since the previous reply: I'm indeed seeing an item getting blocked (bottomAd); I've looked around and didn't see anything obvious that could have changed in this release (as stated by @justinvelluppillai). That message was definitely not showing up before the upgrade though (I've got Matomo in a pinned tab, I would have noticed).

I'm not sure why that's happening all of a sudden then. Since you folks seem to consider this is not a bug, I suppose I'll patch out the twig include in my installation, and call it a day.

This warning already existed for a long time with no changes in Matomo 4.9.0.

For me the message definitely appears only since the update to Matomo 4.9.0.

That's interesting. The code of that template hadn't changed since 2018. Wondering why it should suddenly start blocking it, unless there was an update in the adblocker maybe.
In general disabling the adblocker for Matomo only should fix any such issues.

I was trying to check https://github.com/easylist/easylist's history (that's the trigger according to uBlock Origins), but got tired of waiting for deltas to be resolved on that ~ 3G repository…

Sure, disabling the adblocker for Matomo might work as a general solution might work.

I don't understand why I would have to do that.

Going back in the twig file's history, I'm seeing #12493 mentioned. It seems the intent was use within the installer. I'm on the front page of my instance. Why should I turn my adblocker off?

While disabling the easylist filter in Adblock Plus works for me I want to note that I did the Matomo update ~ 1 hour ago. The last filter list update was done a few hours earlier on my system. It would also have been a very big coincidence if the filter list would have been updated in exactly the same moment as Matomo.

@CyrilBrulebois #12493 was not just intended for the installer, but also all other pages in Matomo. And this check has been there indeed since 2018.

Everyone, do you by chance have your Matomo instance installed on a subdomain called matomo.yoursite.example?
Then it might be caused by this rule in the easyprivacy filter list:

easylist/easylist@ece9fd8#commitcomment-56844920

[Update: No, it seems like this is another unrelated issue]

Everyone, do you by chance have your Matomo instance installed on a subdomain called matomo.yoursite.example?

In my case it's analytics.yoursite.example. And the linked change was commited in September 2021, so it would not explain why it suddenly happens after the Matomo 4.9.0 update.

Whether I'm using an ad blocker is absolutely none of Matomo's business.

That's of course fully true (and I assume most Matomo users use ad-blockers).
The reason for this is just that ad-blockers often block the core JS package of Matomo with overly broad rules. And as this breaks Matomo in unexpected ways, it's very helpful if a message is displayed at the same time.

That said, maybe the check could be improved. At the moment it seems to check if a bottomAd element gets modified. But maybe instead it should check if the Matomo core JS is loaded (by putting the code that hides the message there).
Then again this might make the message flash for a short amount of time on every page load until the JS has been loaded, which also isn't ideal.

@cadeyrn That's true, that is probably unrelated.

I think I can reproduce this issue now that I added an exception rule (@@://matomo.$domain=~matomo.org ) for the rule above and enabled ublock origin again for my site.
Weirdly enough it still doesn't appear on demo.matomo.cloud even though the bottomAd is also hidden there.
I think there might be some timing issue in the JS of _adblockDetect.twig.

I'm using numbers. as a subdomain here, not matomo..

The easylist update seems like a red herring too, finally retried a git clone on a machine with more cores, and git blame suggests that rule has been here since forever or so:

commit 8058e2f5866d67094d5782d4f52abf9252f0a135
Author: Ares2 <ares2mail@gmail.com>
Date:   Mon Nov 30 00:54:14 2009 +0100

@Findus23 I'm not able to reproduce that with my installed adblocker. If you find a way to fix / improve that feel free to create a PR against next_release so we can include that in Matomo 4.9.1

The timing issue hypothesis (or something similar) seems possible to my rather inexperienced web debugger eyes: once the demo page is loaded, using Firefox's debugger to run parts of the detection function correctly gets wasMostLikelyCausedByAdblock = true.

@CyrilBrulebois this looks like it's related to the Vue migration as some code is no longer loaded in a blocking manner. Can you check if this change fixes the issue for you: #19106 ?

@diosmosis Sure thing: wrapping the code inside that DOMContentLoaded listener makes the issue disappear, thanks!

(Tested by hitting Refresh a few times with that change applied, all good; undoing the change makes the issue come back immediately.)

I just joined, to report that I am seeing this horrible message about the adblocker.

Obviously I am not going to disable my ad blocker for anyone :D

Is there a manual way to remove it entirely?

Thank you.

@LauraTaylorUK you can apply the changes from this PR: https://github.com/matomo-org/matomo/pull/19106/files
Otherwise a fix will be included in 4.9.1, which should be released soonish.

Thank you for the prompt fix and support.

Maybe now is a good time to ask, why there is a adblock detection script included in the admin interface?

Maybe now is a good time to ask, why there is a adblock detection script included in the admin interface?

Mainly for the reason I explained here: #19097 (comment)

There are too many ill-configured ad-blockers and overly broad blocking rules that break Matomo and when it does it often does in ways that makes Matomo look broken. And the adblocker is often not the first thing people think of when debugging.

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/fur-den-fall-dass-sie-einen-ad-blocker-verwenden-deaktivieren-sie-diesen-bitte-fur-diese-seite-um-sicherzustellen-dass-matomo-problemlos-lauft/45558/2