I agree that this is a "management problem" in the sense that if you want to support Firefox, you should allocate resources for testing on Firefox.

But also - it's not high up the priority list given Firefox's marketshare. In most cases, you'll get the support by default, but I don't really see many US managers being tasked with allocating resources to support UC browser, or Opera, and those are both in the same space marketshare-wise.

My management is actively discussing EOLing several Firefox products because we have basically no real paying customers on them, and Mozilla is unpleasant to deal with in the extension space (genuinely - https://www.neowin.net/news/ublock-origin-lite-maker-ends-fi...)

You're right, although you'd probably find that in many shops developers have the latitude to use Firefox off their own initiative if they so chose.

I recently finished a 7 year stint at a company where I was CTO. I always made it clear that we needed to be testing functionality in more than just Chrome because, apart from anything else, a good chunk of our users would be on mobile, and many of those on iOS (i.e., using Safari). I used Firefox as my main browser for probably 4 - 5 of those 7 years, and I suggested engineers do the same because it tends to hew closer to web standards than Chrome does (meaning that if it works in Firefox it'll almost certainly work in Chrome, but the reverse doesn't necessarily hold). That gradually bled through the development team, with a number of the engineers using Firefox as their main browser. That's really all it needs is a few people using it for their day to day work.

I made the change on principle because I could see the way the wind was blowing and - even then - Google were doing plenty of things I didn't like. I like to think that influenced the team as well but, reality check, they probably did it to avoid me moaning at them about bugs running in Firefox all the time.

I have never had a manager that said “don’t make it work for firefox”.

What I have seen is developers do it wrong to start, then tasks to fix it get low priority due to market share based priority.

I had one who did say "don't make it work for firefox" but he was the only one.

The basic mechanic is that the off brand browser has to work hard to be compatible whereas the dominant browser works hard to be incompatible. If you develop Firefox first (have some really ideological devs) you'll find Chrome related bugs eat up 1% of your time if that. If you develop Chrome first you'll find supporting other browsers is a bear.

(In the early 2000's when IE was dominant I was afraid it wouldn't be possible to browse the web with Linux. I worked at a library that would have deployed Sun Rays as public computers if we could get Mozilla to compile on Solaris but we couldn't, even with the help of Sun support. I developed Mozilla-first and then Firefox-first and helped keep the flame alive back then.)

The system I work on now works on both because I develop Firefox-first. There's one screen that loads up 40,000 rows (crazy you say?) worth of data that performs fine on Chrome and is laggy on Firefox, but otherwise the site spins like a top on both of those. Once in a while we run into a serious headscratcher on mobile Safari that burns up some dev*weeks.

This is why I always develop to web standards and not to any browser. You follow the web standards and then check to see which browsers do it right. Then adjust for that browser if necessary.

> There's one screen that loads up 40,000 rows (crazy you say?) worth of data that performs fine on Chrome and is laggy on Firefox

Firefox's performance engineers are eager for bug reports! You can record a performance profile [1] and file a performance bug report in Bugzilla [2]. It helps if the slow page is accessible to Firefox engineers for testing, but your performance profile is a big head start.

[1] https://profiler.firefox.com/

[2] https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp...

Early fall 2023 it certainly feels like I caught Verizon discriminating against Firefox. It was a CSS issue in their payment portal where some information wasn't rendering as a DHTML popup but at the bottom of the page. You could still pay your bill, but to an untrained eye it looked broken. I reported it and was sent to "Executive Custom Service", which would never acknowledge the problem. They would call once a week and make some statements like the problem was on my side and they couldn't reproduce it at all, to which my BS meter kept responding "I don't believe you." After several weeks of this, the issue mysteriously disappeared one Saturday morning, with no further word to me. I'd also complained to my state PUC (this was a landline bill) and think the added pressure helped convince them to do the right thing, even though the PUC has no online jurisdiction.

At the time I hadn't thought to go back to tech support and ask somebody there to simply try it with Firefox. Then Verizon would have been pointing fingers at themselves.

Any Verizon developers here? I'd love to know the real story.

Aggressive ad blockers are often the cause of many “site doesn’t work in Firefox” issues. When the Firefox user then loads the site in Chrome, it works because the user doesn’t have an ad blocker installed in Chrome (because they don’t typically use Chrome) or their ad blocker hasn’t updated its blocklists recently.