Based on what you've told us
here, that's a bit weird.
Thing is, we only have half the story. We don't know what else happened in the meeting you were terminated, or got said or happened in the 3 weeks, we don't know what you did and didn't ask your mentor, we don't know how many roadblocks you hit because you're using Firefox and VS Code, we weren't there for the conversation there was about you using Chrome and Visual Studio, or more importantly, how you reacted. We don't know how good you actually are with Firefox and VS Code. If you're struggling to use Firefox and/or can't use VS code very well, which means no one else on the team can help you, and you actively discourage their efforts to help you, I could see that being a red flag.
That said, there are a few quotes elsewhere in this thread that give me an inkling that it's not about Firefox and VS code.
> So my question is, is it fair to terminate a new developer because they use Firefox?
Why is fair relevant? Fair is for board games with your family. This is the real world, and people in power can be as petty as they want. There's no principal of the tech industry to complain to, very little protection (assuming you're in the US, in an at-will state). There's no review board that says yup, that was unfair unless you're a protected class, and was constructively fired for being black/gay/old.
> They gave me a CSS ticket to fix one page last week, and I actually fixed all the pages!
I mean, it's important to get all of the pages, so it is important that you got all of them, but if you're telling us that you got all the pages, it sounds like there was a meeting that contained additional feedback for you, about how you did/finished the ticket and your attitude about it, and that was your defense in that meeting. Don't get me wrong, you sound hungry for it by pushing your boss to get the ticket - which is a good thing! (In certain environments, anyway.)
> as a senior dev with over 15 proven experience, he should not stress to much about HOW I do it, just WHAT I deliver, and WHEN it is delivered. I guess that was asking for to much? Or being insubordinate?
The "what" is quite important. Did the. senior dev/someone talk to you about how they'd like the fix implemented, and did you do it that way? How did the code review go? Are there formal code reviews?
Let me guess: you've heard yourself being described as insubordinate before?
As a senior dev, it's not just about what you deliver, or when you deliver, but also how you make people feel when you do it, especially as a jr dev. If you told the sr dev during your termination meeting instead of listening to what you were being told, and that "telling truth to power" is important enough to you that telling us that you said that to the sr dev really says there's more going on than Firefox and VS Code. It's possible that they "knew" that telling you that you need to work on social skills X, Y, or Z was going to go poorly, and Firefox and VS code is cover for you being difficult to work with and/or a bad cultural fit fit for the team.
> What I did say was that I rarely use browser debuggers, because I've just never felt the need to. The console.log and a good mental image of what the code is doing has got me this far.
It didn't get you very far in this job. If you have to stop to add a console.log ever time you have a question about the code instead of just setting a breakpoint and investigate the state at the point with built-in tools, I question your efficacy. If this were, say the Linux kernel that's a different story, but you're not, you're a frontend developer. Which are important these days, but a good one should have more tools in their toolbox than just console.log. It's fine to lean on that first, but it shouldn't be your only tool.
On the other hand, they could also be a bunch of jerks who suck, or there was some other power play in the company that resulted in the team losing headcount, but to save face to the rest of the team, they concocted this thing about Firefox.