3 ms·
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
by jlokier 6y ago
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?
- takluyver 6y agoI 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.
- nitrogen 6y agoIt'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".
- the-dude 6y agoAre you hacking our website?!?!?! ?