Confirmed users
290
edits
(Update Bugzilla Component to Blocklist Policy Requests) |
(Clarify pre-91 Android brokenness) |
||
Line 39: | Line 39: | ||
* Until version 41 (bug [https://bugzilla.mozilla.org/show_bug.cgi?id=1162530 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 41 (bug [https://bugzilla.mozilla.org/show_bug.cgi?id=1162530 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1714673 1714673]) blocklist entries fetched after installation did not apply on Android; only the list that shipped with the application was used. 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. | * 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. |