undefined | Better HN

0 pointsthe-dude5y ago0 comments

Are you sure it was FF and not the adblocker?

0 comments

3 comments · 1 top-level

jlokier5y ago· 2 in thread

Of course not.

There's also no way to be sure it was FF in general and not the particular version(s) of FF Beta I was running at the time.

There is no way to know which of numerous factors might contribute without running from a blank profile, which isn't something anyone would do unless really keen on investigating a problem, as it's easier to just run a different browser instead.

If a payment process gets stuck due to an FF-specific adblocker, I'd still count that as an accident of implementation affecting FF users, because final stage payment processes don't have any reason to call up ad-blocked services, and most FF users use an adblocker, don't they?

takluyver5y ago

I periodically see sites broken in Firefox until I turn off uBlock and/or Privacy Badger - including issues with paying like you describe. But I've always assumed that the same would happen in Chrome if I had the same extensions installed there. This seems more like 'locking out people with adblockers' than 'locking out Firefox', even if there's substantial overlap.

nitrogen5y ago

It's distressingly common for JS developers to just throw something like "t.track('payment')" in the onclick handler for the last button (or every button) in a payment flow, where "t" is some analytics package you've blocked. No exception handling, of course, so when the analytics package isn't loaded, nothing happens when you click the button. If you're lucky, there will be a console message logged saying something like "unable to call method track on undefined".

1 more reply

j / k navigate · click thread line to collapse