> I don't think it's the FireFox' team's responsibility to be aware of and take into account arbitrary software intercepting system calls.
One of the first, hard lessons I had to learn about web development (like, stare-at-a-wall-and-consider-my-career-hard) is that web development is way more about network effects than application architecture.
Real people run systems with real configurations, and when you're targeting "the public" as your userbase you must account for that. And Mozilla knows this: if you go into the source code (circa 2009, YMMV) and look through the initialization and boot-up logic, you would find places where the system used heuristics to figure out whether some extensions had been installed in odd places instead of the "Extensions" directory (because the tool had been installed before Firefox) and hot-patch paths to pull in that component. Because if a user installs Flash and then installs Firefox and Flash doesn't work in Firefox, it's not Flash that's broken... It's Firefox.
It doesn't matter if the bug is in "Microsoft's code" or "Mozilla's code." That's unimportant. If you're a Mozilla engineer, all that matters is whether this bug would cause a user to get pissed off and uninstall Firefox.
I completely agree with you and have been on the other side of this too, having worked on a native enterprise app running on various MacOS, Windows, iOS and Android versions. Customers don't care if you have a great explanation why stuff with your app doesn't work. That being said, it's completely unreasonable to have the proactive expectation of something working well today (writing many files) breaking tomorrow (due to defender heuristics changing) and proactively trying to prevent this by optimizing. Mozilla reacting to this by both reporting the bug to Microsoft and optimizing to work around the problem is really the best you can do.
"They shouldn't have written so many files in the first place" is not a valid preventative strategy, but a one way road to premature optimization hell.
One of the first, hard lessons I had to learn about web development (like, stare-at-a-wall-and-consider-my-career-hard) is that web development is way more about network effects than application architecture.
Real people run systems with real configurations, and when you're targeting "the public" as your userbase you must account for that. And Mozilla knows this: if you go into the source code (circa 2009, YMMV) and look through the initialization and boot-up logic, you would find places where the system used heuristics to figure out whether some extensions had been installed in odd places instead of the "Extensions" directory (because the tool had been installed before Firefox) and hot-patch paths to pull in that component. Because if a user installs Flash and then installs Firefox and Flash doesn't work in Firefox, it's not Flash that's broken... It's Firefox.
It doesn't matter if the bug is in "Microsoft's code" or "Mozilla's code." That's unimportant. If you're a Mozilla engineer, all that matters is whether this bug would cause a user to get pissed off and uninstall Firefox.
Thats. All. That. Matters.