Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ad block shouldn't break your checkout

ilakovac.com

Post reply on HN
Print view View original

11–20 of 204 posts

Re: Ad block shouldn't break your checkout

#11

Post by suprfsat »

tyingq wrote: post #9
al2o3cr wrote: post #6

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

Re: Ad block shouldn't break your checkout

#12

Post by tyingq »

suprfsat wrote: post #11
tyingq wrote: post #9

Earlier quoted context omitted.

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?

Re: Ad block shouldn't break your checkout

#13

Post by bellyfullofbac »

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

Re: Ad block shouldn't break your checkout

#16

Post by GuB-42 »

LinuxBender wrote: post #7

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?

It makes no sense. All these ads and tracking and all that is to make people buy stuff.

If people are ready to give you money, don't try to stop them!

Re: Ad block shouldn't break your checkout

#17

Post by IvanK_net »

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.

Re: Ad block shouldn't break your checkout

#18

Post by lainga »

bellyfullofbac wrote: post #13

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…

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!
Post reply on HN