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.