Live data from Hacker News

Ad block shouldn't break your checkout

ilakovac.com

51–60 of 204 posts

Re: Ad block shouldn't break your checkout

#51
post #18

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!

Similar story with Dominoes UK, where signin doesn't (or didn't a couple of weeks back) work with uBlock.

Re: Ad block shouldn't break your checkout

#52
post #48

Practically the whole Web doesn't function if client blocks add, disables JavaScript (which became quite annoying lately) or uses Tor. I'd like to find a solution which would restore the ability to use sites. I'm thinking about website cleanup offering (startup anyone?), I wonder if something similar already exists.

I use Tor by default, and while many sites don't work (TFA is behind a Cloudflare captcha, ironically enough), I wouldn't say it's a majority.

Re: Ad block shouldn't break your checkout

#53

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.

Don't put GA there, then.

Re: Ad block shouldn't break your checkout

#54

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

Re: Ad block shouldn't break your checkout

#55

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…

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.

Re: Ad block shouldn't break your checkout

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

Re: Ad block shouldn't break your checkout

#57

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.

The *adblocker crowd. I think I'm in the "technical crowd" but I've never used an adblocker. Running non-compliant extensions is your right, but the results don't need to be supported. I've run into this situation a number of times, although not with adblock. My advice has been to disable the extensions, or use a different browser without them.

> My advice has been to disable the extensions, or use a different browser without them

You're leaving out the option of "not using the website."

Let's face it, nothing for sale on TeeSpring is essential. Just thank them for putting a roadblock on your silly impulse buy.

Re: Ad block shouldn't break your checkout

#58

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.

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

Re: Ad block shouldn't break your checkout

#59
post #41
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.

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?

Re: Ad block shouldn't break your checkout

#60

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

If it had broken, the code in the post would have worked. How exactly is code supposed to handle a dependency existing, but not being the API shape that it should be because a browser extension added an incomplete stub? Should every line of code get 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."

Post reply on HN