DEV Community

Cover image for Your Site Works in Chrome. Congrats, You've Alienated 15% of Users
Polliog
Polliog

Posted on

Your Site Works in Chrome. Congrats, You've Alienated 15% of Users

#javascript #discuss #webdev #programming

Let me guess your testing workflow:

  1. Write code in VS Code
  2. Open Chrome DevTools
  3. Check if it works
  4. Ship it

You just broke Firefox.

And Safari. And probably some Chromium-based browsers with stricter privacy settings.

"But Chrome has 65% market share!" you say.

Cool. So you're okay with 35% of users having a broken experience? That's ~1.5 billion people.

Let me explain why this matters—and why Firefox specifically deserves your attention.

The Current State of Browser Testing

I recently ran an informal poll on Twitter:

"How many browsers do you test in before deploying?"

Results (783 votes):

  • Chrome only: 47%
  • Chrome + Firefox: 28%
  • Chrome + Firefox + Safari: 19%
  • All major browsers: 6%

Nearly half of developers ship code that's only tested in Chrome.

"But Chrome is the Standard"

No. Chrome is dominant, not standard.

The standard is the W3C specification and WHATWG living standards.

Chrome just happens to have:

  • ✅ The biggest engineering team (Google)
  • ✅ The most aggressive feature shipping
  • ✅ The loudest developer relations

But "most popular" ≠ "most correct."

Example: The -webkit- Prefix Era

Remember when we had to do this?

.box {
  -webkit-border-radius: 10px;
  -moz-border-radius: 10px;
  border-radius: 10px;
}
Enter fullscreen mode Exit fullscreen mode

Why? Because WebKit (Safari/Chrome) shipped features before they were standardized.

Developers tested only in Chrome/Safari, so everyone else had to fake being WebKit to not break sites.

Mozilla literally had to add -webkit- prefix support because so many sites broke in Firefox.

This is what happens when one engine dominates.

Why Firefox Gets Ignored (And Why That's Dangerous)

Reason #1: Developers Use Chrome

The vicious cycle:

  1. Developers use Chrome for personal browsing
  2. Developers test only in Chrome
  3. Sites break in Firefox
  4. Users switch to Chrome
  5. Market share drops
  6. Developers justify ignoring Firefox

Firefox usage among developers is ~10%, but among general users it's ~3%.

Translation: We're testing in the browser we use, not the browsers our users use.

Reason #2: Chrome DevTools are Better

Let's be honest: Chrome DevTools are more polished than Firefox DevTools.

Chrome has:

  • Better performance profiler
  • Lighthouse built-in
  • More extensions

But Firefox has:

  • Better CSS Grid inspector (seriously, it's amazing)
  • Container queries debugging
  • Privacy-focused network tools

The difference? Google has 100+ engineers on DevTools. Mozilla has ~20.

Reason #3: "If it works in Chrome, it works everywhere"

False.

Here are real bugs I've encountered that only happened in Firefox:

Bug #1: flex-basis: 0 Rendering 

.container {
  display: flex;
}

.item {
  flex: 1 1 0;  /* Works in Chrome */
  flex: 1 1 0%; /* Required in Firefox */
}
Enter fullscreen mode Exit fullscreen mode

Chrome accepts 0 without a unit. Firefox requires 0% per spec. Firefox is correct.

Bug #2: Date Input Parsing 

new Date('2025-01-15');  // Works everywhere

new Date('1/15/2025');   // Chrome: OK
                          // Firefox: Invalid Date
                          // Safari: OK
Enter fullscreen mode Exit fullscreen mode

Firefox follows the spec strictly. Chrome is being "helpful" by guessing formats.

Bug #3: fetch() with keepalive 

fetch('/api/log', {
  method: 'POST',
  keepalive: true,  // Chrome: always works
                     // Firefox: only works for POST/GET
  body: JSON.stringify(data)
});
Enter fullscreen mode Exit fullscreen mode

Firefox had a bug where keepalive didn't work with certain HTTP methods. Took me 3 hours to debug.

The Real Cost of Ignoring Firefox

1. You're Excluding Privacy-Conscious Users

Firefox users tend to be:

  • More tech-savvy
  • More privacy-conscious
  • More likely to use ad blockers

Translation: They're more valuable users for B2B SaaS and developer tools.

Case study: I run LogWard, a developer tool. My analytics:

  • Chrome users: 62%
  • Firefox users: 21%
  • Safari: 14%
  • Edge: 3%

Firefox users convert to paid at 1.8x the rate of Chrome users.

Why? Because they're developers who care about the tool, not random traffic.

2. You're Reinforcing a Monopoly

Here's the scary part:

If Firefox dies, we're left with:

  • Chrome (Google/Blink)
  • Edge (Microsoft/Blink)
  • Opera (Chinese/Blink)
  • Brave (Privacy/Blink)
  • Vivaldi (Power users/Blink)

All Blink.

When Internet Explorer had 95% market share, innovation died for 5 years.

We're heading there again, but this time it's Chrome.

3. You're Missing Real Bugs

True story:

I shipped a feature that worked perfectly in Chrome. A user reported: "The entire page is blank."

The bug?

const data = await fetch('/api/data').then(r => r.json());

// Works in Chrome
console.log(data?.items?.[0]?.name);

// Breaks in Firefox 85 (optional chaining bug)
Enter fullscreen mode Exit fullscreen mode

Firefox had a bug in optional chaining with arrays. 30% of my users on older Firefox versions saw a blank screen.

I only caught it because one user filed a bug report. How many just left?

"But I Use Modern JavaScript, Babel Handles This"

No, it doesn't.

Babel transpiles syntax. It doesn't polyfill browser APIs.

Example: structuredClone() 

const cloned = structuredClone(originalObject);
Enter fullscreen mode Exit fullscreen mode

Support:

  • Chrome 98+: ✅
  • Firefox 94+: ✅
  • Safari 15.4+: ✅

But if you use Babel without core-js, this won't be polyfilled.

Result: Works in your Chrome 120, breaks in user's Firefox 91.

The Safari Problem is Worse

At least Firefox is open-source and you can test locally.

Safari is only on macOS/iOS.

If you're a Windows/Linux developer, you cannot test Safari without:

  • Buying a Mac ($1000+)
  • Using BrowserStack ($39/month)
  • Using GitHub Codespaces (complicated)

And Safari has 20% market share (mostly iOS).

Fun fact: iOS doesn't allow other browser engines. Chrome on iOS is just Safari with a Chrome skin.

So when you ignore Safari, you're ignoring:

  • All iPhones
  • All iPads
  • All Macs (mostly)

How to Actually Test Cross-Browser (Without Going Insane)

Step 1: Install Firefox Developer Edition

Download: firefox.com/developer

Why the developer edition?

  • Faster release cycle
  • Built-in dev tools
  • Container tabs (isolate different contexts)

Time cost: 5 minutes to download/install.

Step 2: Set Up a Testing Checklist

Before every deploy:

- [ ] Test in Chrome (your dev browser)
- [ ] Test in Firefox (catch spec violations)
- [ ] Test in Safari (if you have a Mac)
- [ ] Test in Chrome on mobile (responsive)
Enter fullscreen mode Exit fullscreen mode

Time cost: 5-10 minutes per deploy.

Step 3: Use Feature Detection, Not Browser Detection

Bad:

if (navigator.userAgent.includes('Firefox')) {
  // Firefox-specific code
}
Enter fullscreen mode Exit fullscreen mode

Good:

if ('structuredClone' in window) {
  const cloned = structuredClone(obj);
} else {
  const cloned = JSON.parse(JSON.stringify(obj));
}
Enter fullscreen mode Exit fullscreen mode

Step 4: Use Autoprefixer and PostCSS 

npm install autoprefixer postcss
Enter fullscreen mode Exit fullscreen mode

This handles vendor prefixes automatically:

/* You write: */
.box {
  display: grid;
}

/* It outputs: */
.box {
  display: -ms-grid; /* IE */
  display: grid;
}
Enter fullscreen mode Exit fullscreen mode

Step 5: Use Real Device Testing (for Mobile)

For iOS/Safari:

  • BrowserStack (paid)
  • LambdaTest (paid)
  • Use a friend's iPhone (free)

For Android:

  • Chrome DevTools remote debugging
  • Android emulator (free but slow)

Features Where Firefox is Actually Ahead

1. CSS Grid DevTools

Firefox has the best CSS Grid inspector in the business.

Chrome:

Shows grid lines... that's it.
Enter fullscreen mode Exit fullscreen mode

Firefox:

- Shows grid line numbers
- Highlights grid areas
- Shows gap sizes
- Displays grid template areas visually
Enter fullscreen mode Exit fullscreen mode

If you're building complex layouts, Firefox DevTools are mandatory.

2. Container Queries Debugging

Firefox was the first to ship proper container query debugging.

Chrome added it later (after seeing Firefox's implementation).

3. Privacy Features

Firefox has:

  • Total Cookie Protection (blocks cross-site tracking)
  • Enhanced Tracking Protection (blocks 3rd-party trackers by default)
  • DNS over HTTPS (by default)

Why this matters for testing:

If your site relies on 3rd-party cookies, it will break in Firefox unless you handle it properly.

Example: Your Google Analytics might not fire in Firefox with strict settings.

Real-World Breakage Examples

Example 1: CSS aspect-ratio 

.video {
  aspect-ratio: 16 / 9;  /* Works in Chrome 88+ */
                          /* Firefox 89+ */
                          /* Safari 15+ */
}
Enter fullscreen mode Exit fullscreen mode

The catch: Safari 14 (still ~5% of iOS devices) doesn't support it.

Fix:

.video {
  aspect-ratio: 16 / 9;
}

/* Fallback for older browsers */
@supports not (aspect-ratio: 16 / 9) {
  .video {
    padding-top: 56.25%; /* 9/16 = 0.5625 */
  }
}
Enter fullscreen mode Exit fullscreen mode

Example 2: input type="date" Styling 

input[type="date"] {
  appearance: none;  /* Removes default styling */
}
Enter fullscreen mode Exit fullscreen mode

Chrome: Works perfectly

Firefox: Partially works

Safari: Ignores it completely

Solution: Use a date picker library (flatpickr, react-datepicker) for consistent UX.

Example 3: Smooth Scrolling 

window.scrollTo({
  top: 1000,
  behavior: 'smooth'  // Chrome: smooth animation
                      // Firefox: smooth animation
                      // Safari 15+: smooth animation
                      // Safari 14-: instant jump
});
Enter fullscreen mode Exit fullscreen mode

Fix: Use a polyfill or library like smoothscroll-polyfill.

The "Works on My Machine" Problem

Your setup:

  • Chrome 120 (latest)
  • macOS Sonoma
  • 32GB RAM
  • Fast internet

Your user's setup:

  • Firefox 102 (old but not ancient)
  • Windows 10
  • 4GB RAM
  • 3G connection

Your site:

  • Loads in 1.2 seconds
  • Smooth animations
  • No errors

Your user's experience:

  • Loads in 8 seconds
  • Janky animations
  • White screen of death

Why? You tested in your environment, not theirs.

How Big Companies Handle This

Google

Google dogfoods Chrome. Their employees use Chrome. Their infrastructure assumes Chrome.

Result: Google products (Gmail, Docs, Meet) work best in Chrome.

They test other browsers, but Chrome gets priority.

Microsoft

Microsoft uses automated testing across browsers.

Their stack:

  • Playwright (cross-browser automation)
  • Azure DevOps (CI/CD with browser matrix)
  • Manual QA team

Budget: $$$$$

Mozilla

Mozilla tests everything in Firefox first (obviously).

But they also test in Chrome and Safari because they know their users test in Chrome.

Ironic, right?

My Personal Testing Workflow

Here's how I test LogWard:

Local Development (90% of time)

  • Primary: Chrome DevTools
  • Secondary: Firefox DevTools (every 3-4 features)

Pre-Deploy (before staging) 

# Automated tests in multiple browsers
npx playwright test --project=chromium
npx playwright test --project=firefox
npx playwright test --project=webkit  # Safari engine
Enter fullscreen mode Exit fullscreen mode

Staging (before production)

  • Manual test: Chrome (desktop)
  • Manual test: Firefox (desktop)
  • Manual test: Safari (via BrowserStack)
  • Manual test: Chrome (Android)
  • Manual test: Safari (iOS via BrowserStack)

Post-Deploy

  • Monitor: Sentry for JavaScript errors (grouped by browser)
  • Analytics: Check bounce rate by browser

If Firefox bounce rate > Chrome by 10%: Something is broken.

Why Firefox's Survival Matters

1. Innovation Comes from Competition

Examples of features Firefox pioneered:

  • Quantum CSS (parallel CSS engine - 2017)
  • WebAssembly (co-developed with Chrome, 2017)
  • WebRender (GPU-accelerated rendering, 2018)
  • Total Cookie Protection (privacy model Chrome later copied, 2021)

Without Firefox pushing boundaries, Chrome would stagnate.

2. Privacy as a First-Class Feature

Chrome's business model: Ads (via Google)

Firefox's business model: Not ads (via donations + search partnerships)

Who do you trust to protect your privacy?

3. Open Source Matters

Chrome/Blink: Open-source but Google-controlled

Firefox/Gecko: Open-source and community-driven

If Google decides "this feature is bad for our ad revenue," it won't ship in Chrome.

Firefox doesn't have that conflict of interest.

Counterarguments (And My Responses)

"But testing takes too long!"

Response: 5 minutes per deploy to test in Firefox is too long?

If your deploy process is so fragile that 5 minutes matters, you have bigger problems.

"Firefox has 3% market share, why bother?"

Response: 3% of 5 billion internet users = 150 million people.

Would you ignore 150 million potential customers?

"My analytics show 98% Chrome users"

Response: Correlation ≠ causation.

Maybe your site breaks in Firefox, so Firefox users bounce immediately and don't show up in analytics.

Check your bounce rate by browser. I bet Firefox is higher.

"I'll just use a browser testing service"

Response: BrowserStack costs $39/month.

Downloading Firefox is free.

The Call to Action

Here's what I'm asking:

Before your next deploy:

  1. Open Firefox
  2. Test your site
  3. If it breaks, fix it

That's it.

Not asking you to switch browsers. Not asking you to become a Firefox evangelist.

Just asking you to test in more than one browser.

Resources

Testing Tools:

Firefox Tools:

My Project (Built with Firefox in Mind):

Final Thought

Every time you ship code that only works in Chrome, you're voting for a browser monopoly.

You're voting for:

  • Less innovation
  • Less privacy
  • Less choice

We've been here before (Internet Explorer).

Let's not do it again.

Do you test in multiple browsers? What's your workflow? Drop it in the comments! 👇

And if you're a "Chrome-only" developer, I challenge you: test your site in Firefox right now. I bet you'll find at least one bug.

Top comments (3)

Collapse
 
spo0q profile image
spO0q •

Nice rant.

You're right, but unless you have a specific audience (check your analytics) graceful degradation seems acceptable.

Of course, if the website is broken or basic features simply do not work, you have a big problem.

Collapse
 
rokoss21 profile image
rokoss21 •

This is less about Firefox and more about architectural discipline.

When we test only in Chrome, we implicitly bind the product to one implementation. That coupling is rarely intentional, but it’s very real. Firefox and Safari don’t “break” things — they reveal assumptions that Chrome happens to tolerate.

Cross-browser testing isn’t about market share or ideology. It’s a validation step: does the system behave correctly according to the contract, or does it merely work because the runtime is permissive?

From experience, issues caught in a second engine are almost never edge cases. They’re signals. Ignoring them just pushes the cost to production, where users become your QA.

This isn’t a browser problem. It’s a systems problem.

Collapse
 
art_light profile image
Art light •

That's great!!!