It's not even a NN-type middlemen issue for me, though that is exactly what's going on here. The bigger problem for me is causing regressions for users. On top of that they're causing regressions just because they don't like X traffic, and they're not even exclusively affecting X traffic - they're affecting unrelated traffic too. It's just an incredibly arrogant, annoying, bad thing to do to users who never requested this to begin with.
Should only affect pre-broken code. Like complaining that a compiler is doing something with undefined behavior than you wanted: I get that it's annoying, but maybe fix your code so it's not a problem?
This isn't even a broken code issue. This is a totally unnecessary functionality regression issue. Instead of just loading a page, they're waiting four seconds to load the page, because the page uses an asset on a domain they flag as a tracking domain.
This is like if the compiler generated loops with 4000ms sleeps because the app links a library the compiler thinks is annoying.
Technically the compiler never said it wouldn't add random sleeps into loops. It's totally in spec! What's the big deal?
Meanwhile, my app is slow now. Or in the case of some apps, actually broken for active use cases where it used to work fine. Which, again, is totally regression by any QA standard.
You make it sound like Firefox is just adding a wait for no reason.
The reality is that the page is asking Firefox to download dozens or hundreds of scripts [1]. Firefox needs to prioritize those loads somehow, because it generally doesn't want to open that many connections to the server in parallel. So it prioritizes the non-tracking bits over the tracking ones. If all the non-tracking bits are done loading, the trackers start loading at that point.
> This is like if the compiler generated loops with 4000ms sleeps
No, it's more like if your OS scheduler decided to prioritize some applications over others based on how much it thinks you care about them (e.g. based on whether they're showing any UI, or based on whether they're being detected as viruses by the virus scanner).
[1] For example, http://www.cnn.com/ shows 93 requests for scripts in the network panel in Firefox. If I enable tracking protection, that drops to 37 requests.
Or for another example, http://www.bbc.co.uk/news has 67 script requests and only 20 with tracking protection enabled.
Or for another example, https://www.nytimes.com/ has 150 script requests and only 40 with tracking protection enabled.
Much of this discussion is missing that the point is to _speed up_ page load/display. It is NOT like a compiler generating sleeps.
The bazillion tracking scripts loaded by pages is slowing down time to view/interaction on the page. Firefox is taking scripts that are _already_ being marked as loadable asynchronously/delayed, and delaying them until the page is otherwise loaded. That's it. It's not an arbitrary 'sleep', it's an attempt to prioritize UI responsiveness over tracking scripts.
To the extent it breaks or _slows down_ pages, that's an undesired side effect, not the goal. If it does that to a lot of pages, the feature won't be succesful and will be rolled back, I bet.
Your app is only slow now if you are blocking its content and/or most basic usability on the loading of external trackers - a lame yet increasingly common practice that needs to stop.
According to the article, they're only delaying these resources when loaded dynamically or async - so developers should be able to "fix" this by loading tracking scripts synchronously, which is what they are effectively doing already if this new FF behavior causes any noticeable impact.
It's hard to feel much sympathy for devs who have _explicitly_ prioritized the sending of their users' info to external parties, over their sites being baseline usable.
