Perhaps some companies have the resources to check if their websites run with different ad blockers, but expecting websites to work when plugins are replacing and breaking running code is a big ask.
There's a big difference between "resilient against a missing dependency" and "being resilient in the face of getting literally any object instead of the dependency you expected to get."
Everything Google Analytics does is expendable, so the block of code that deals with it should be wrapped in try/catch.
> There's a big difference between "resilient against a missing dependency" and "being resilient in the face of getting literally any object instead of the dependency you expected to get."
If Google pushes a breaking change to the Google Analytics API tomorrow, that shouldn't break checkout either.
For third party dependencies that might not get loaded for whatever reason? Yes, sure. There are better ways to do it, but that's the idea.
I think TeeSpring has the right idea - they're checking that GA is loaded, if it is, then do stuff with it, if it's not, then don't.
I don't understand how a website can and should be expected to adapt to a browser plugin changing the APIs they depend on out from underneath them.
I think they could go one step further and may be try...catch (sandbox) all access to third-party services that aren't critical.
User-agents, which browsers are, expectedly do put a lot of control in the hands of the end-users. Such breakages should be factored in and worked around (provided there are enough engineering resources to throw at the problem, of course).
Put it this way, forget adblock, if the GA call fails, it should still check out. (Assuming the problem doesn't affect other stuff too, like internet down or whatever.)
Given the hyper-malleable nature of JavaScript in an HTML page in a user-agent owned by the end user, at some point the developer has to draw a line in the sand and say "This category of failure modes is not checked," because it's mathematically impossible to check all possible failure modes in that configuration. "An extension is intentionally faking an object in the `window` context" just happens to be on the other side of the "don't check" line for this application, because it's extremely unlikely (and, one could argue, user-self-inflicted).
Checking the top 3 adblockers that command the majority of market share would be a much smaller ask - maybe smaller than a check-mobile-browser sized ask.
So the reason why the GA object is replaced, rather than removed, is because removing it would break other sites. Tee Spring is trying to do the right thing, but fail because other sites don’t do the same.
Ignore it at your peril. If you want to make sales, you need to test the ways your prospective customers want to buy.