Blocklisting/Graphics
Blocklisting graphics drivers is the process of causing Firefox to not use some or all of its hardware acceleration features on a given device, potentially for a limited set of driver versions.
Contents
Blocklisting Policy
Graphics drivers can crash Firefox and/or your computer. Buggy drivers can sometimes crash in a recoverable way, but even these recoverable driver crashes can annoy users and cause other programs to misbehave or crash.
Block Conditions
Acceptable reasons for blocking graphics drivers include:
- Firefox startup crashes
- Frequent (multiple times per day) recoverable driver crashes
- High crash volume inside the driver
- Severe performance impact
- Firefox drawing bugs caused by the driver
Block Type
Drivers can be blocked via a downloaded blocklist or via compiled-in blocklist. The downloaded blocklist is carried as part of the regular Firefox blocklist ping, and as such cannot block startup crashes. The compiled-in blocklist, however, needs a new build of Firefox to take effect, which is much higher-cost and hence should be avoided whenever possible.
How to request a block
- Read the policy above and be sure your request meets the criteria
- File a bug using the appropriate request form and filling in all requested details:
- The request will follow the process outlined below until resolved.
If there is an existing bug to be morphed into a blocklist request, make sure the required information (indicated in the request template) is included in the bug before moving it to Toolkit :: Blocklist Policy Requests. Please do not move bugs to Blocklist Policy Requests until they are ready for blocklist consideration.
Blocklisting Process
- A request is filed with detailed information as described above
- The request will be discussed in the bug among the Firefox drivers, graphics developers, and other interested parties to agree upon validity of the request, block ranges, and type.
- The agreed-upon blocklist entry will be placed on the blocklist staging server for anyone to help test.
- QA will verify the graphics driver blocklist on staging, and that the blocklist does not affect unrelated devices.
- The Blocked Graphics Drivers page will be updated with details on the block.
- The blocklist item will be pushed to production.
Blocklisting Details and Limitations
There are some things that one should be aware of when modifying or interpreting the blocklist for graphics.
- Until version 41 (bug 1162299) any features in the blocklist would be interpreted as "all features" by the versions that do not know about those features. For example, FEATURE_STAGEFRIGHT was added in Gecko version 17. If FEATURE_STAGEFRIGHT was added to the downloadable blocklist, all versions prior to version 17 would automatically block all features that otherwise match that blocklist entry.
- Until version 41 (bug 1162530) all blocklist entries applied to all Gecko versions. We introduced the graphics blocklist entry versioning, which let us specify the minimum and maximum version that any particular blocklist entry applies to. Note that the versions include nightly/aurora/beta suffixes, so if you wanted a blocklist entry to apply to all versions after version 42, for example, you would specify minVersion as 43.0a1.
- Until version 91 (bug 1714673) blocklist entries using remote settings were not applied. The only blocklist entries that worked were the ones shipped at compile time. Earlier builds will need a dot-release if the blocklist changes in a way that affects Android.
- Downloadable blocklists are usually only downloaded once a day, and cached in the profile directory (as blocklist.xml.) Modifying that file is often the best way to do local testing of changes, before proceeding with the staging of the modified blocklist file.
- Even with the local blocklist file, note that we don't necessarily check against it every run, so your testing should involve multiple runs.
