uBlock-issues: where uBlock Origin reports belong, and which ones get closed on arrival

A tracker that holds no code

The repository top level contains exactly two entries, a .github directory and README.md, and the project description says it is the community-maintained issue tracker for uBlock Origin. There is no source tree, no build system, no test suite and no package to install. Anyone deciding whether to depend on it should understand that immediately, because nothing here can be vendored or imported.

What the repository does is decide where a report should go. The README is a set of routing rules, and each one exists because the wrong kind of report was being filed here. That makes it useful to anyone who has filed a uBlock Origin bug and received a closed issue with a pointer elsewhere, and useful to anyone who wants to know the shape of the project's issue policy without reading several hundred threads.

The main tracker itself lives at gorhill/uBlock, which the README links as the uBO repository. The split between the code repository and this tracker is worth keeping straight, because the name similarity makes it easy to file an issue in the wrong place.

Five categories of report and where each one belongs

The README names four distinct destinations, and each one is tied to a different part of the uBlock Origin project.

Support questions go to the support forum at /r/uBlockOrigin on Reddit. Filter list issues, which the README describes as issues with filter lists or broken website functionality, belong in the uAssets issue tracker. Issues specific to the Manifest Version 3 variant go to the uBOL issue tracker, since uBOL is the MV3 variant of the extension. Localization issues, meaning language translations, are handled at Crowdin on the project page there. And WebRTC issues have their own rule, described below.

Two of these are worth emphasising. The uAssets tracker handles both filter list problems and broken website functionality, so a site that fails to be filtered is not a uBlock Origin core bug and should not be filed on this tracker. And the MV3 variant has a separate tracker because the extension behaves differently under Manifest Version 3, so a problem that only appears in the MV3 build belongs in uBOL, not in the main issue tracker.

The Crowdin route is the one that surprises people most. Translation is a continuous, distributed process across many languages, and a translation fix filed as a code issue against the extension has no obvious owner. Routing it to Crowdin keeps the source strings in one place.

The performance report bar, and why unprofiled claims are closed

The performance section is the strictest rule in the document, and it is short enough to quote. Speculated performance issues are marked as invalid and closed if they do not come with actual profiling data from the Firefox Profiler, or from the Firefox Profiler for Chromium, together with a fully substantiated analysis supporting the claim.

That is a high bar, and it is deliberate. Performance complaints about a content blocker are the kind of report that is easy to make and hard to act on, because the report itself rarely contains the data needed to identify the cause. The README does not claim the rule is there to deflect complaints, only that speculation without profiling data is closed.

Practical consequence for a reporter: install the profiler, record the session while reproducing the slowdown, and attach the profile. The README names two profilers, one for Firefox and one for Chromium, and a fully substantiated analysis is required in addition to the raw data, so a trace alone does not satisfy the requirement.

For a maintainer, this rule explains why the tracker can stay usable. A tracker where every vague complaint becomes a thread is a tracker where the real regressions get buried.

WebRTC leaks are explicitly out of scope

The WebRTC section contains the most absolute statement in the README, and it is worth reading closely because it contradicts a belief many users hold.

Do not open issues about WebRTC leaking local IP addresses. The stated reason is that supported modern browsers do not cause undue local IP address leaks through WebRTC. The README adds that uBO is not a VPN or proxy tool, and that if you are experiencing such an issue, you should report it to the browser or to the VPN or proxy software provider, or to both.

The reasoning behind this is easy to reconstruct from the sentence structure. A content blocker filters page requests, and WebRTC traffic is a browser-level mechanism. If a local address is being exposed, the fix belongs in the component that implements WebRTC, which is the browser, not in the extension that filters requests. The README's own framing of uBO as not a VPN or proxy tool is the key: users expecting a VPN's behaviour from a blocker will file reports that a blocker cannot fix.

This is a policy, not a technical fix, and it has a cost. A user whose address is genuinely exposed gets redirected to a forum or a vendor rather than helped here, and the tracker will not hold the thread for them.

Filter list requests and the two categories that are closed on arrival

Two rules in the README close issues without a technical discussion, and they are the two most likely to frustrate someone filing for the first time.

The first is filter list requests. New filter list requests are not permitted and will be declined and closed. Note the scope: the rule is about requesting new lists, not about reporting that an existing list misbehaves, which the README routes to the uAssets tracker. A user who wants uBlock Origin to start maintaining a list of their preferred sites will get a closed issue, and the README gives no alternative channel for that wish. A user who found a bad entry in an existing list gets a proper tracker.

The second is the performance and WebRTC rules described earlier, which also end in closure but at least point somewhere.

The pattern across all of these is that the tracker handles defects, not proposals. If you have a change you would like to see in the project, this is the wrong place, and the README does not describe a separate feature request process.

Development builds for catching regressions early

The last part of the README is about the builds you should be testing before a stable release, and it is the one piece of actionable instruction aimed at contributors rather than users.

The guidance is to use the development builds to help report issues and regressions before the next stable release. Once you install a development build, it automatically updates when a new version is published, so you stay on the current development head without manually reinstalling.

The build artifacts are named by platform and browser, and each is picked from the uBO Releases page on the gorhill/uBlock repository.

The three artifact names, as they appear on the releases page, are the chromium build named uBlock0_[version].chromium.crx, the Firefox build named uBlock0_[version].firefox.signed.xpi, and the Thunderbird build named uBlock0_[version].thunderbird.xpi.

The Thunderbird case has a version constraint that is easy to miss: drag and drop the xpi into Thunderbird's Add-ons Manager pane, and Thunderbird 91 or later is required. The Chromium and Firefox artifacts are signed and packaged for their respective install paths, and the version placeholder in the file names is filled by the release, so you always take the most recent one rather than searching for a specific build.

The practical effect is that the fastest way to find a regression is to run a development build for a few days and report what breaks, rather than testing the stable release and reporting the same class of bug after it ships.

Editorial conclusion

Treat uBlock-issues as a routing table rather than a software project, since the repository contains only a README and a .github directory and no code to adopt. Use it to decide where a report belongs: filter lists go to uAssets, MV3 problems to uBOL, translations to Crowdin, and performance claims need Firefox Profiler data or they get closed. Do not open new filter list requests there, because the README states they are not permitted and will be declined and closed, and do not file WebRTC local IP leak reports, which the README redirects to the browser or VPN vendor.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. uBlockOrigin/uBlock-issues on GitHub