Hacker News Reader

Comment by al2o3cr | Hacker News Reader

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.

View on HN

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.

If GA is unreachable then window.ga wouldn't be defined.

The author is running an extension that specifically injects code to make window.ga into something unexpected, and then complaining about it.

Yes, though again, throwing out a checkout session for anyone running that extension isn't wise.

"If GA is unreachable then window.ga wouldn't be defined."

The legacy code you insert for GA does: var ga = document.createElement('script'); first, then loads GA. Wouldn't that have the same issue if GA is unreachable?

Doesn't matter. Anything that is not the main goal (in that case, the checkout process) should be isolated and not break it.

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.

If a purchase occurred on the internet and Google didn't know, did it really happen?

Funny. But why do I feel sad?

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.

Reply on news.ycombinator.com