pixellint

Firefox on iOS can block listed pixel hosts with EasyList before your CAPI worker ever sees a click id.

· 12 min read

Check your payload in the playground →

Hybrid measurement decks still assume the browser pixel misfires only when Intelligent Tracking Prevention caps a cookie or when consent denies ad_storage. That story misses a whole iPhone browser where the failure happens earlier: the network request to facebook.com/tr or google-analytics.com never starts because a filter list matched the host. On September 1, 2026, Mozilla shipped an optional Ad Blocker inside Firefox for iOS that uses Apple's WebKit Content Blocker technology and the EasyList filter list to block many third-party ads and ad-related trackers before they load. Trade coverage picked the feature up again on October 25, 2026 alongside Firefox AI controls, which matters because measurement teams segment on Safari versus Chrome, not on Firefox-with-blocker versus Firefox default.

The same October week brought WebKit's October 19 post on blocking identity resolution infrastructure, which we covered as a resolver-domain failure distinct from third-party pixels. Firefox iOS Ad Blocker is the EasyList class of failure: listed vendor hosts dropped at load time, while first-party page ads and search ads Mozilla documents as out of scope still render. Your GTM preview can show fbq fired while WebKit never fetched the Graph pixel URL. Conversions API POSTs that only copy fbc or gclid from a browser hit that never left the device will look like CAPI is broken when the real gap is optional ad blocking on a browser share your analytics export probably labels mobile Firefox.

This post is dated news about a browser product change on the collector lane, not a field table from our docs. The argument is that list blocking and ITP are different knobs on the same purchase, and that server-side backfill must persist click identifiers on first party before any listed third-party host is required to load.

What Mozilla's Ad Blocker actually stops

Mozilla describes Ad Blocker for Firefox on iOS as a built-in option that blocks many third-party ads and ad-related trackers before they load. The implementation names two concrete inputs: Apple's WebKit Content Blocker framework and the EasyList filter list. Users enable it under Settings, then Browsing, then Ad Blocker. Mozilla states it is off by default, which means measurement impact is opt-in but invisible in aggregate reports that do not read Firefox settings flags.

Mozilla also documents limits that matter for triage. Ad Blocker will not block every ad. Ads served directly by the site you are visiting and ads shown in search results will still appear. Sponsored shortcuts when opening a new tab are separate from page ads and are not affected. That boundary is how retail sites keep house promo banners while Meta and Google vendor paths die: the block is third-party list logic, not a global JavaScript off switch.

Ad Blocker works alongside Enhanced Tracking Protection on Firefox iOS, which Mozilla's wiki describes as content blocking using Shavar tracker lists formatted for WebKit, with Standard versus Strict modes that differ on third-party cookie blocking for advertising and analytics trackers. ETP can block or block-cookies per category; Ad Blocker adds EasyList's ad and ad-tracker rules on top. A conversion stack can therefore fail on ETP alone, on Ad Blocker alone, or on both, while the page still looks interactive in Tag Assistant because the tag manager container executed.

Why this is not Safari 27 and not a hashing fix

Safari's October identity-resolution block stops domain-level resolver infrastructure even when vendors scope graphs to one company. Firefox iOS EasyList blocking stops requests that match known ad and tracker hosts, the same class of hosts our ad-blockers doc names for desktop uBlock. Neither failure is fixed by normalizing email SHA-256 on the server. If fbc never minted because facebook.com/tr was list-blocked, hashing the checkout email does not recreate the click attribution window the platform expected for that campaign.

CNAME cloaking and server-side GTM on a first-party subdomain can keep the browser talking to infrastructure you control, but EasyList evolution and WebKit content rules can still catch paths that look like collectors. Mozilla's iOS constraint is structural: extensions are not available the way they are on desktop Firefox, so ad blocking had to ship inside the app. That increases the share of Firefox iOS users who can enable blocking without installing a separate Safari content blocker app.

Compare to rtblint.org's Safari 27 work on adsrvr.org and bidstream user.eids: that is auction identity thinned before your pixel fires. Firefox iOS Ad Blocker is downstream on the page the bid already won. Both show up as missing joins in the same Monday dashboard unless you tag the browser, the protection level, and whether Ad Blocker was enabled.

Two hops on the same checkout, only one leaves the phone

Illustrative sequence; list names and block reasons come from Mozilla's EasyList plus ETP documentation, not from a single vendor test device.

Landing after paid click (Firefox iOS, Ad Blocker ON):
  document: gtag('event', 'page_view') runs
  network: GET https://www.google-analytics.com/g/collect?...  → blocked (EasyList / content blocker)
  first-party: no gclid cookie persisted on your domain

Thank-you page CAPI worker:
  POST https://googleads.googleapis.com/... UploadClickConversions
  user_identifiers: { hashed_email: "..." }
  adIdentifiers.gclid: (empty)

Same user, Ad Blocker OFF, ETP Standard only:
  /g/collect may still fire unless Shavar advertising cookie rules apply
  hybrid dedup may work if you copied gclid on landing

The code block is the production argument in miniature. JavaScript execution and network fetch are not the same event. Tag Manager's data layer can advance while WebKit's content blocker suppresses the vendor host. Server-side teams that only monitor CAPI 2xx responses will see successful uploads with weak match rates and blame hashing or event_time, because nobody logged that the browser never attempted the pixel GET.

Meta's hybrid dedup expects a browser event_id or fbp when both hops fire. List blocking removes the browser hop entirely for listed hosts. Sending CAPI alone is valid API usage and still undercounts relative to a campaign optimized on pixel-visible audiences unless your match keys come from first-party capture on the landing URL before any third-party script loads.

Google enhanced conversions and UploadClickConversions have the same split: hashed email helps modeled matching; gclid on the click path helps click-through credit. Firefox iOS with Ad Blocker ON is another browser column where gclid never lands in a third-party cookie because the Google collect host was blocked before Set-Cookie mattered.

Checklist for collector owners

Ad Blocker uses Apple's WebKit Content Blocker technology and the EasyList filter list to determine what gets blocked.

Mozilla, Ad Blocker for Firefox on iOS, September 1, 2026

What to expect next

Mozilla frames Ad Blocker as optional because advertising funds the open web. Opt-in does not mean rare: Firefox users who install the browser for privacy often enable every protection toggle. iOS distribution also means App Store reviewers and Apple's WebKit API constrain how blocking evolves, but EasyList updates ship on Mozilla's schedule and can add hosts without a press release your analytics team reads.

The October 25 news cycle pairing AI controls with ad blocking is a reminder that Firefox product surface is moving on two axes: what runs in the page and what gets blocked from the network. Measurement vendors will keep selling CAPI-first narratives. Your job is to prove first-party capture on landing before listed hosts are required, then lint the server JSON separately.

Pixellint is independent of Mozilla. Validating that a CAPI payload matches vendor schema does not detect WebKit content blocking; it catches the class of mistakes that leave server events empty of click ids after the browser silently skipped the pixel. Read the sibling Safari resolver post when email login stops reaching identity hosts; read this one when Firefox iOS reproduces missing /tr or /collect with no consent denial and no ITP cookie cap in the trace.

If hybrid measurement is the plan, treat optional Firefox iOS Ad Blocker as a permanent stratum in QA matrices alongside Safari and Chrome, not as an edge case you will fix when someone files a ticket from a Mozilla forum.

Sources

Contract pages

The dated argument is above. These pages are the field lists.

Read ad blockers and tracking pixels Docs