• Declared an Android compatibility floor of 120. AMO validation flagged
  permissions.request as unimplemented at the stated minimum, and it was
  right: per Mozilla's compatibility data that API landed in Firefox for
  Android 120, while the manifest claimed 109. Below 120 the "Allow on
  facebook.com" button in both the popup and the setup page would have done
  nothing at all — on the one platform 1.1.39 exists to serve. 120 is also
  where Firefox for Android gained general extension support, so it is the
  floor at which any of this is installable anyway.

gecko_android sets a compatibility range separate from desktop, which is
what it is for. Desktop stays at 109.


AMO still warns that data_collection_permissions postdates the stated
minimum (140 desktop, 142 Android). Those are left alone deliberately: it is
a manifest key, unknown keys are ignored by older browsers, and nothing
behaves differently. Silencing them would mean raising the desktop floor from
109 to 140 — cutting off every user between — to quiet a cosmetic warning
about a key whose entire content is a declaration that no data is collected.

• Works on Facebook's mobile web layout. Installed on a phone the
  extension hid nothing at all, while looking perfectly healthy: permissions
  granted, content script injected, no errors. Three separate faults were
  stacked behind that, each invisible until the one before it was fixed.

Container resolution had nothing to anchor to. Mobile web ("weblite" —
it tags ` withhtml-renderer) is a different app, not a narrow
desktop. It exposes no ARIA landmarks whatsoever: norole="article", noaria-posinset, nodata-pagelet, norole="complementary", and the
author header is a plain<div>rather than a heading. Every strategy infindPostContainerkeys off one of those, so all of them returnednull.findMobilePostContainerclimbs instead: that layout's feed is a single
container whose direct children are the posts, so the post is the last
ancestor before the first ancestor with many children. A width check
rejects nested carousels, which can also clear the child-count bar. Forunfollowed, the label must sit inside the container's first child —isAuthorLevelLabel`'s "don't hide a post over a quoted author's Follow
button" rule, expressed without headings to key off.

Ad labels were unmatchable. Weblite draws its icons from a font mapped
into the Private Use Area and packs them into the same span as the text, so
an ad's label is literally "Ad\u{F078B}\u{F17E0}". Those glyphs are
category Co, and INVISIBLE_CHARS_RE stripped only Cf and Mn, so the
cleaned text never equalled "Ad". This is precisely why mobile hid
unfollowed posts but never ads: "Follow" happens to sit in a span of its
own, with no icons alongside it.

The decoy filter threw the labels away before either fix could matter.
isImplausiblyShallow treats anything within 10 levels of ` as a
portal/decoy span, which holds on desktop where real posts sit 15+ deep.
Weblite's entire document is about 11 levels and an ad label measures
exactly 10, so every real ad was discarded before resolution was attempted.
The limit is now layout-aware (MOBILE_SHALLOW_DEPTH_LIMIT`).

Desktop behaviour is unchanged. The Co strip does apply to both, but it
can only shorten text: the neighbouring organic-post span is a timestamp
plus the same icons, "1h\u{F212D}\u{F3196}", which cleans to "1h" and
matches no target. Confirmed against a live desktop feed as well as mobile.

• The DEBUG perf line now reports MutationObserver cost separately. It
  previously timed scanRoot only, so everything the observer callback does
  including cacheLabelTargets walking every subtree Facebook inserts during
  its initial render was invisible. That blind spot had already hidden one
  regression: the retry-loop freeze fixed in 1.1.35 reported a healthy
  1.0ms across 274 scans while the page was unusable.

Measured on a real feed, the observer costs 2–16ms per 2s window and falls
after load rather than spiking during it, which ruled it out as the cause of
a slow first paint that had been attributed to it.
- README leads with an Install section pointing at the store listings.
Both sideload sections are now labelled Development: a temporary add-on
disappears on restart and never updates, so it is the wrong way to install
this for normal use.

No behaviour change in release builds: the instrumentation is DEBUG-only.

• A setup page opens once, on first install. The popup prompt added in
  1.1.36 only helps someone who opens the popup, and a new Firefox user has no
  reason to: the extension appears installed and simply does nothing. The page
  explains that facebook.com access is still needed and requests it directly.

It reads the current permission state rather than assuming: where access is
already granted always the case on Chromium it shows a short "you're all
set" confirmation instead of asking for anything. Gated on
reason === "install" so upgrades don't reopen it, and the tabs.create
call is wrapped, because failing to open a setup page must not take the
background script down with it.
- build.ps1 copies onboarding/. The payload is an explicit file list, so a
new directory ships only when added here — worth remembering when adding
another.

The feed stopped loading. 1.1.30 queued any element carrying an
aria-labelledby whose target didn't resolve, on the theory that ad labels
arrive late; 1.1.33 then tightened the retry loop to one frame. Facebook has
a great many elements with dangling label references a 300-post feed
carries roughly 1,800 — so the queue flooded and every entry was
re-examined every 16ms for the full 8s window.

The theory was wrong regardless: late-arriving labels were never what hid
feed ads. Following the sprite reference (1.1.32) was. That queueing is
removed, and the retry loop is back to 50ms.
- The retry queue is now capped (MAX_PENDING_LABELS). It exists for ads
staged in a hidden node and reparented a moment later, which is a handful of
entries at most; a future change that queues too eagerly should degrade
detection, not the page.

Added CHANGELOG.md for version update notes

F.B. Sponsored/Ad Post Blocker — 1.1.20

Fixed
Sponsored posts were not being hidden at all. Facebook's scrambled "Sponsored" label pads the real characters with decoy spans, distinguished by class-list length — but the direction of that signal had flipped. The filter was discarding the real characters (~22 classes) and keeping the decoys (~7). Detection now assembles every plausible partition and matches against any, so a future flip can't silently kill it again.
Hidden posts immediately reappeared. Any node added inside a hidden post was treated as Facebook recycling the container, and the post was restored. Ads mutate constantly after being hidden (video players, lazy-loaded media), so they were un-hidden within milliseconds — and never re-examined, because scanning only ever runs on newly-added nodes. Restoring now re-checks the evidence first.
Group posts were wrongly hidden. A post embedding a shared post inherited the quoted author's "Follow" button, so a group you're a member of quoting someone you don't follow was hidden entirely. Follow/Join now only counts for the post's own author.
The toolbar counter reset by itself. The background script is an event page — Firefox suspends it after ~30s idle, discarding the in-memory tally. The badge then jumped back to 1 while the popup reported 0. The count is now read back from the badge itself, which survives suspension, with per-tab serialisation so concurrent updates can't lose increments.
Performance
Element text is now read only on leaves and character-split labels. Wrappers are skipped — the leaf holding the text is visited in its own right, so reading wrappers re-walked the same subtree once per nesting level.
The getComputedStyle walk is gated behind a structural check, instead of running on any element with two or more children.
Facebook's portal accessibility spans (<span id="r…_">, which contain the word "Sponsored" but belong to no post) are dropped before entering the retry queue.
Unfollowed labels no longer enter the retry queue — a Follow button and its author header always render together, so retrying can't change the outcome.
Changed
DEBUG now defaults to false. When enabled it reports the running build version, a rolling scan-cost summary, and unresolved matches capped at 15.
README rewritten to correct several stale claims and document the traps.
Known issues
Right-column sidebar ads are detected but not hidden. They have no aria-posinset, and the sidebar no longer carries the role="complementary" landmark the fallback relied on. Hiding nothing was preferred over risking an over-broad match.
Unfollowed detection assumes the post's own author header is the first heading in the post. If it isn't, those posts are missed (fails quiet rather than hiding wrongly).
Feed ad detection rests on the scrambled-text path; the "… sponsored content" aria-label only matches sidebar ads. Some feed ads may slip through.
English-language labels only.

Fixes a bug where a "Follow [creator]" button in a Reels comment panel could be mistakenly resolved through the sidebar ad detection path, incorrectly hiding the entire comments panel. The "hide unfollowed Pages/Groups" feature no longer uses that fallback at all, it's now restricted to genuine feed posts only. No other behavior changes.

Reels' comments/info panel could get incorrectly hidden. Root cause: the "hide posts from unfollowed Pages/Groups" feature was matching a "Follow [Reel creator]" button and climbing up to the nearest role="complementary" ancestor to decide what to hide, a fallback originally built for the main feed's right column ad sidebar, but FBs also happens to mark a Reel page's entire comments panel with that same role="complementary" landmark. The "unfollowed" detection no longer uses that sidebar fallback at all; it's now restricted to sponsored/suggested content only, which is what it was actually validated against.