Your checkout shouldn't trigger ad block. Stop slavishly bowing to GA everywhere. I'm about to give you money. That's the only 'analytic' you should care about.

I'm tired of being treated as little more than a data cow, always ready for milking.

Just. Stop.

To the person who ignores people who complain because their 'non-standard' browsers fail on their site, why do you have a site if you don't care about your users accessing it? Ego much?

I remember trying to order from a pizza place that talked to a third party delivery site, I hit "Order" and the browser didn't do anything. DevTools told me it tried to talk to the 3rd party using HTTP although the page was in HTTPS, and the browser blocked it (this was years ago when browsers started blocking HTTP content on HTTPS sites). Modifying the submit URL to https solved the problem.

I found it pretty funny that I had to understand web development and troubleshoot the problem just to order pizza...

Hang on: The Tee Spring code checks if GA is there and works without it, the website breaks because Ad block replaces GA with a fake object that doesn't have the same API.

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.

I’ve been running into this sort of thing more and more and more. It’s crazy how many page rely on some kind of google tag manager event before they’ll load the real content or perform the main function of the page.

Don’t all developers have ad blockers (clearly not)? I understand managers not testing for this, but for my own work it’d never load for me as a Dev, even.

IMO, this points out the inherent and unresolveable contradiction between browsers being a user-agent, and browsers being a precisely-specified execution environment for arbitrary applications. A browser that is built to operate in the interests of its user will not run code that is harmful to them, whether that's code to track them, code to mine bitcoin, or code to display advertisements. On the other hand, a browser that is compliant with the (largely advertising-company-defined) web platform standard will do all these things, and can't permit any user-agent features or extension mechanisms that would interfere with them. The web platform standard as we know it essentially specifies that the browser belongs to the website operator (within some sandboxing guarantees), not to the browser user. On the whole, I prefer that software I run on my computer belong to me; this makes using the web a necessary evil at best.

TBH I don't see this as a TeeSpring problem - the code on their page guards against a realistic scenario (the GA script fails to load), but the "break" is caused by uBlock's changes.

The article's title is correct: ad block shouldn't break checkout. Injecting a bogus value into a global breaks checkout, so ad block shouldn't do that.

I've used adblock for so long that I completely forget it's even there. Consequently, I also forget how shitty most the internet is without it.

I never even thought about or realized that adblock may be why I have had issues with many different online retailers. I just assume "something is fukt with the site, or my browser, Vivaldi, is at fault" and then just buy the product elsewhere or buy a different/similar product instead.

My local energy company has a website where you can register an account to pay remotely with them. I have uMatrix on and it was blocking some third party scripts. It managed to get my account into some sort of "half-created" state. It is impossible to log in, impossible to reset the password, and impossible to create a new account with my (physical!) address because "an account already exists for that address". I ultimately found another solution, but that's the worst breakage I've ever seen... not just that my payment didn't go through, but my browser config permanently scrambled the entire possibility of ever getting an account set up!

(I did not bother trying to explain this to a human on the phone, because of the aforementioned alternate solution. That just sounds a supersized order of pain.)

I am an author of a photo editor https://www.Photopea.com .

Whenever someone reports a bug to me, I ask them if they use any site-modifying extensions. If they do, I ignore them completely, even if they wrote a long, detailed report.

Web authors make websites for standard web browsers. I do not consider a browser with site-modifying extensions to be a standard web browser, and it is not my job to test my website with all 1,000,000 extensions that exist on earth.

It all started six years ago, when my website contained <div id="ad" ... and somebody reported, that their adblock removes that element, but it is not the ad. What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

While we're at it, potential customers shouldn't need to identify pictures of traffic lights and buses to shop your store. If you're a web store, then you're in the business of selling things and advertising that you're selling them far and wide. The only place you might need a CAPTCHA is the account login page, and only then after there are multiple failed attempts from the same IP address. Other than that, get the fuck out of your customers' way.

Why is it checking for GA at all? A critical function like accepting payment should be bullet proof. It's critical code and should be treated that way.

Adblock doesn't break sites. If your site doesn't work with adblock, that means your site is broken.

27% of American internet users use adblock in some form. Better go check right now that you're not losing 27% of sales to it.

I’ve reported this to Teespring and all they reply with is to try another browser and clear my cookies. They won’t listen. They’re basically making Teespring unusable for the technical crowd.

I think you need to consider changing the title of your article. If I understood correctly, you're saying: TeeSpring needs to fix their stupid checkout. I think your title should be: Your checkout should not break because of ad-block. You have it the other way around. It's important because most people understood it like how I initially did and I was prepared to write a lengthy comment on how wrong this argument is.

It's your job to fix your site so it doesn't break because of ad-block. If you're determined on refusing service for people who don't want to be tracked by breaking checkout, that's fine as well. But then you don't get to complain.

Side note: my pet peeve these days is emojis. People need to stop it with shoving emojis everywhere, just like TeeSpring needs to stop shoving evil analytics everywhere. Not everything needs to have 4x emotional emphasis ffs.

Some critical sites I need to pay through are so fundamentally broken by uBlock Origin and uMatrix that I've been forced to use the embedded browser in the LastPass app.

Since they're utility bills, credit cards, insurance portals, etc, I don't really have a choice not to use their services.

Also ad block should not break log-in process. I recently discovered that I could not log in to a web site unless I disable ad block. All core web site functionality should be tested to work with ad blocking. Unless you really hate your users.

I never ceased to be amazed at how much core site functionality is implemented with Google Tag Manager.

I block it with uBlock Origin and many standard ecommerce sites just don't function in a most basic way.

This is the most infuriating thing ever. Plus checkouts that rely on constant popups for authentication and confirmation which usually get blocked too.

I basically have to switch to another browser to actually checkout on anything because there's so many things I'd need to disable to get them to work.

Fairly regular support conversation on the community website I run:

"I can't see the images on the 'Adverts' page."

"Do you have an ad-blocker installed?"

"Yes."

"What do you think an ad-blocker does..."

Is the issue that the store built a checkout dependency on google analytics to force people to disable uBlock or attempt to force uBlock to allow google analytics for this domain?

I also hate when sites use ever-changing 3rd party urls (e.g. $randomchars.cloudfront.net)

Use uMatrix on a site for more than a week and annoyances will show themselves. Twitch is the biggest site I've found that loves ever changing 3rd party urls.

Let me add that blocking outgoing requests to non-standard ports should also not break payment systems, yet I've encountered exactly that.

If your checkout system connects over anything but port 443, you done fucked up.

My fave example of this - I am using NextDNS for ad-blocking on my stock Pixel 4a, the Wells Fargo app won't allow me to sign in with fingerprint or username/pass while using DNS over TLS.

British Airways does this. It's been broken for years.

Low quality JavaScript shouldn't break your checkout. This is the type of issue that could have been caught by aggressive type checking.

> Hi, is this pizza abc?

> Yes, can I take your other?

> No, you don't get it, I'd like to file a bug report, but your website clearly has no feature to create issues so, when the field city has the value...

> Sir, I cannot fix the website. If you do not wish to make an order please hang up.

> Uhoh ok, sure, I'd like an anchovies pizza but instead of anchovies I'd like you to make sure that when the field city is set to Boston...

> Sir, I really cannot fix the website

> Couldn't you just make a note and leave it in the front door? So that if other customers have the same problem they can upvote the most common issues and then you can prioritize fixes and get a reasonable budget for each one?

> I obviously can't do that, do you want your anch...

> Of course you can't! That would be reinventing the wheel! Let me point you to the github...

Same thing happened to me with Domino's Canada. The call to place the order was returning a well-structured JSON error message (it didn't recognize the city I had entered, which was my suburb rather than my "post town") but the front-end wasn't telling me anything!

Reminds me of pizzatool. Today, probably nobody under 40 would have ever used it. https://instructabest.blogspot.com/2019/07/the-story-of-sun-...

I've gotten a little more paranoid in recent years and started blocking outgoing requests, just as a defense in depth. So I would prevent clients from connecting to anything but 22, 80 and 443 (to start; I added more for things like WebRTC and Amazon Streaming which uses AWS). I found a checkout that was connecting over some random port and wouldn't work until that was unblocked. Fucking annoying and I'm just left wondering how long until they have a security breach through their non-standard proprietary bullshit.

I tried to order something from an online store, the “place order” button did nothing. The json response was nice enough to tell me to contact their bank responsible for the payment integration. A part of me wonder how things would turn out if I followed their instructions.

I think the point is that Google Analytics shouldn't be an essential part of your site, so it totally breaking for any reason should be unnoticeable to the end user.

Yeah this is very clearly on the ad-blocker.

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.

But you don't even need to check, you just don't blow up and still check out if it doesn't work?

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.)

> Perhaps some companies have the resources to check if their websites run with different ad blockers,

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.

I believe that Firefox is replacing some Facebook JavaScript with a stub, to avoid that sites break because some tracking bits are missing.

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.

Don't put GA there, then.

Chrome store says 10 million+ users (I expect it's vastly higher than that) 24,000 reviews. Firefox says 5 million users and 12,000 reviews.

Ignore it at your peril. If you want to make sales, you need to test the ways your prospective customers want to buy.

Just stop using Google spyware. Takes zero amount of resources.

I do see it as a TeeSpring problem. This particular bug got in my way 2 weeks ago when I was attempting to buy some merch to support a youtube channel I frequent. I almost abandoned the purchase.

A shopping site breaking checkout when there's a google analytics problem is madness, IMO. uBlock Origin is hugely popular. With 10M (claimed) active users, you should probably be testing against uBlock Origin for your e-commerce site.

As an aside, buying from TeeSpring was a little... interesting. You add the items to your cart and pay like at any other site. Instead of being charged for the total, I got invoiced separately for each (including separate confirmation emails), along with 5 or 6 duplicate shipping notices for one of the items. My credit card was also charged separately for each item. I get that there are probably reasons for this purchase flow, but it's not implemented well.

I got my stuff and all is good, but the whole buying experience was janky.

I agree with that, though if I'm TeeSpring, I'd fix it anyway. It's silly to throw out incoming business. I assume the same thing would happen if there were a brief GA outage.

Personally I think the path should guard against any change to unnecessary third party library function. Because third party script can be bugged and break your site in a funny way. Just like the story broken facebook login broke many site and apps. The api behaves funny, so everything broke all together because you explicitly rely on it without care.

Coupling your checkout to Google Analytics is not good though.

That may be true from a technical perspective, but it ultimately is TeeSprings problem. The problem they face is lost revenue from people who already clicked the purchase button.

It's both.

as mention other places though, missing window.ga at all on other sites can cause worse problems. I'm not sure mimicing the whole api is useful, but maybe not adding the stub on teespring will be.

On teesprings side, it's not their fault, but adding '&& window.ga.getAll' will fix the issue

How does analytics factor into the functionality of the checkout? That's the only question that matters here. The answer is it doesn't, so regardless of if it loads, is buggy, or has weird data, it shouldn't stop the checkout process.

>I do not consider a browser with site-modifying extensions to be a standard web browser

What do you consider a standard web browser?

If someone ships a browser with Tracking Protection (like Firefox), or with NoScript preinstalled (like Tor Browser), or with another adblocker preinstalled, is that a standard browser because the user didn't modify it?

Or is it based on the number of user. Is your standard browser really just Google Chrome, because Google has a lot of marketshare?

I ask, because I looked up the statistics, and they say between 25-45% of users have an ad blocker, depending on the country.

It seems pretty unfair to ignore your users completely, even if they wrote a long, detailed report. No?

> I ask them if they use any site-modifying extensions. If they do, I ignore them completely, even if they wrote a long, detailed report.

Note to self, don't use Photopea due to poor customer support.

You would think the customer support would at least tell them to remove/disable the add-ons instead of ignoring them.

We're talking about a checkout. We're at the end of the sales funnel, where the monetary exchange is finalized, the deal is sealed, the value delivered.

Breaking this based on an ad blocker just loses you money.

> What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

For website owners who are losing revenue, the mental process is simple: "If I change this webpage I will get more sales."

I think that's a fair point of view. I use ad blockers, and if you site breaks with them, I won't use your site. If you're OK with that, I am as well.

div id="ad" but not containing an actual ad, seems like a pretty obvious unintentional overlap, and one that's not going to go away.

How difficult would it be for you to change the div name to not coincide with the characters most closely involved with one of the most contentious technologies around? And never have to deal with that potential conflict again?

> What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

Well, if the extension looks for obvious ad-related layout, and your site just happened to use that name, then yes, you have a bug related to common usage patterns.

Even if you used the name before anything ad related, when the world changes around you, you can choose to adapt, or you can get offended and obstinate and fall further and further into a niche of your own creation.

An update: almost nobody pays for Photopea, and all my reports are from users who use it for free. I fixed over 3000 issues so far, some took minutes, others took weeks: https://github.com/photopea/photopea/issues?q=is%3Aissue+is%...

A "popular" issue is, that people use an extension, which renames files saved by Photopea to .TXT. It is reported several times a week and every time, I tell people to disable an extension. They often argue, that it can not be caused by an extension, or even lie, that they disabled it and it did not help.

https://github.com/photopea/photopea/issues/3246 https://github.com/photopea/photopea/issues/3227 https://github.com/photopea/photopea/issues/3194 https://github.com/photopea/photopea/issues/3187 https://github.com/photopea/photopea/issues/3116 https://github.com/photopea/photopea/issues/3110 https://github.com/photopea/photopea/issues/3049 and so on.

> What kind of a mental process should a brain perform to conclude, that it is a bug in a website, and not in their extension, which is supposed to remove ads.

On the other hand you know how ad blocking works and if it’s not too much effort just change the class name?

If your website behaves like malware is it really the fault of antimalware software that blocks it? If there was a better way to detect malware, sure, but heuristics is the best we’ve got and they do sometimes break - if it’s not too much effort to make your website not behave like malware why not do it?

I fully agree with you about other, more intrusive site-modifying extensions, but ad-blockers are fairly lightweight and only target behavior that looks malicious, and it’s fairly easy not to trigger them.