Factory pattern can return a mock type for testing or a production type, as needed, which makes it possible to unit test the code that uses the produced object.

This quick guide explains it well. Then it improves on it by explaining dependency injection.

https://github.com/google/guice/wiki/Motivation

For what it’s worth, my gut feeling when I read the symptoms was that packets were getting misrouted. I had a similar issue when my NAT was misconfigured, so packets were going out the clear net but with the VPN’s source IP. If so, it would appear as if packets were getting dropped. Those half-open connnections could conceivably cause ns_binding_abort, since the browser is making lots of requests but many of them never get responses. Maybe.

Some other random tidbits, in case they’re helpful:

• When I ran OpenVPN on Android and tethered my PC, the tethered traffic didn’t go over VPN, only traffic originating from the phone did. From what I recall, that was normal on Android. Maybe Mullvad and/or EasyTether changes that. But maybe they don’t change it reliably? I have no idea why that would be Firefox specific, though. You could try ipleak.net to see if it gives you any clues about traffic leaking from your VPN.

• I also recall that some mobile carriers use the TTL on packets to detect tethering. I believe there’s an Android setting that affects that behavior, which you can set with ADB. If the carrier detects that your packets’ TTLs are lower than they should be, they might drop the packets. Again, I have no idea why that would be Firefox specific or sporadic.

Good luck!

Just a guess… Try different settings in https://support.mozilla.org/en-US/kb/dns-over-https (I.e. try Max Protection and Off; either might help.) I’ve had problems with it interfering with VPN.

Another random idea… See if it happens with older versions of Firefox. Maybe they pushed an update in the past few weeks that changed something.

You might find more info in the Firefox developer console (as opposed to the network tab) if you haven’t checked there already.

If I were debugging this, my next steps would be Wireshark, Postman proxy, or Burp proxy, to see what’s actually happening to the packets that are failing.

ALGOL-60 had its own keyboard (sort of): https://retrocomputing.stackexchange.com/questions/16082/was-there-an-input-device-capable-of-entering-all-algol-60-symbols-with-correct