Ability to define an alternative toolbar icon visual when an `allowAllRequests` DNR rule is in effect in top frame

[gorhill]

Typically, when a content blocker is disabled on a specific site, an allowAllRequests DNR rule is in effect in the top-most frame. When a content blocker is disabled on a given site, users expect a different visual for the toolbar icon as an important visual hint.

I had numerous requests[1] to implement the different visual for when the content blocker was disabled (through an allowAllRequests rule), but I resisted for a long while because I didn't want to have the service worker wake up on navigation events just for the sake of 1) verifying that filtering is meant to be disabled on the navigated-to site, and 2) that the toolbar icon should be modified from default one to reflect the disabled state of the content blocker.

Eventually we figured out that the service worker could be woken up only for those sites for which the content blocker is meant to be disabled by using the optional filter property in webNavigation.onCommitted.addListener; such that only navigation to URLs matching the sites for which filtering is disabled would cause the service worker to wake up -- hence the need for webNavigation permission.

Using this approach however means installing an event listener in an asynchronous manner, which means that when the service worker is woken up on a navigation event, the listener has (most likely) not been executed, which then means that the extension must go through all existing tabs to ensure that the toolbar icon is properly reflecting the disabled status of the content blocker -- hence the need for tabs permission.

This work well as far as I can tell, however this approach requires:

1. two new permissions in the manifest just for that one single purpose: tabs and webNavigation [2]
2. the code required to accomplish this [3]

If there was a way to set an alternative toolbar icon for when an allowAllRequests is in effect in the top-most frame in a tab, this would save content blocker authors from having to declare two new permissions, and remove all the code necessary to deal with this common case (all reputable content blockers show a different toolbar icon when disabled on a given sites -- uBO Lite was the exception for a long while).

The declarativeNetRequest.setExtensionActionOptions method seems to be a good place to support such capability, though I am not sure how the optional property under extensionActionOptions should look like, but just to illustrate let's say:

allowAllRequestsActionIcon
An object containing the imageData or path property (as defined in action.setIcon()) to use for tab where an allowAllRequests DNR rule is in effect in the top-most frame.

---

[1] uBlockOrigin/uBOL-home#198
[2] https://github.com/uBlockOrigin/uBOL-home/blob/uBOLite_2025.4.27.1394/chromium/manifest.json#L309-L316
[3] https://github.com/uBlockOrigin/uBOL-home/blob/uBOLite_2025.4.27.1394/chromium/js/action.js

[gorhill]

two new permissions in the manifest just for that one single purpose: tabs and webNavigation

Note that recently I realized there was a better approach not requiring the use of these two permissions[1], but I think the proposal is still valid, because the new approach still requires broad host_permissions.

[1] uBlockOrigin/uBOL-home#198 (comment)

[Rob--W]

Following today's meeting (meeting notes pending publication at #823), we'd like to see a more detailed description of the expected behavior.

Copy of meeting notes:

• [timothy] Content blocking extensions would like a custom icon where DNR is disabled for the top level frame. Suggestion is to add a new option to the existing declarativeNetRequest.setExtensionActionOptions method to allow a custom icon to be specified when allowAllRequests is in effect.
• [timothy] I think it's reasonable and feasible. There is precedent for badging
• [oliver] I'll check with Devlin, but it sounds reasonable to me.
• [rob] Unlike “block” DNR actions, where the outcome is final, the “allowAllRequests” action is more of a “ignore rules below a certain priority”. It is not very obvious what ought to happen, e.g. another extension can also decide to block/modify a request independently of the original extension.
• [rob] Would you consider a new DNR action that would set the action icon? Comparable to Chrome's declarativeContent.SetIcon action.
• [rob] Next step is for interested parties to come up with a proposal (does not have to be a formal proposal, a comment on the issue works too). The proposal should define precisely what the expected behaviors are, so that we can evaluate whether this is something that can feasible be implemented or generalized.

[gorhill]

“allowAllRequests” action is more of a “ignore rules below a certain priority”

allowAllRequests rules are very special, they exist to disable DNR rules that would otherwise be enforced starting at the top frame, and as such a different toolbar icon visual is an important cue to reflect this special state.

If an extension choose to have DNR rules escape an active allowAllRequests, then that is for the extension author(s) to explain how their extension work to their users, that's should not be a concern about whether declarativeNetRequest.setExtensionActionOptions.allowAllRequestsActionIcon exists or not.

It is not very obvious what ought to happen, e.g. another extension can also decide to block/modify a request independently of the original extension

I am not understanding the point being made. If extension A chooses to have a specific visual when an allowAllRequests is in effect in its own DNR rules, extension B should not concern itself about whether extension A has an allowAllRequests in effect in its DNR rules?

[Rob--W]

It is not very obvious what ought to happen, e.g. another extension can also decide to block/modify a request independently of the original extension

I am not understanding the point being made. If extension A chooses to have a specific visual when an allowAllRequests is in effect in its own DNR rules, extension B should not concern itself about whether extension A has an allowAllRequests in effect in its DNR rules?

The meeting notes were shortened from a fuller conversation; the main point was that allowAllRequests is not necessarily the final or the only action. When a request is blocked, it is obvious that it is blocked, and feasible to e.g. maintain a counter of the number of requests. allowAllRequests was designed as a kind of "ignore rules below this priority, in the (sub)resources in this document and all child frames".

As an example of a possible design is "if any allowAllRequests matches in the top frame, set the icon to allowAllRequestsActionIcon".

My question is whether this is sufficient. E.g. a potential question is whether anything else needs to change, such as the tooltip text. Or whether the condition needs to be more broad than "allowAllRequests matched yes/no".

And I'd also wonder about the precedence between the declarativeContent.SetIcon and action.setIcon APIs.

Talking of these APIs, my question is what the conditions for your allowAllRequests rule are. If it is URL-based, the declarativeContent API (currently only in Chrome) can be used to declaratively assign a custom badge icon.

[gorhill]

Ok I think I painted myself into a XY problem corner, so I will step back and instead just plainly explain what I am trying to accomplish:

An alternative visual for the toolbar icon which depends on the URL in the address bar (aka top-most frame).

At the moment to accomplish this requires either the webNavigation/tabs permissions and dubious code[1] for a result with no edge cases.

Currently I revisited this to not need webNavigation/tabs permissions by using a content script, but at the cost of not working properly with some edge cases, for example when the user does not give permissions to inject content script on a given site, in which case the toolbar icon won't toggle to the alternative visual.

declarativeContent.SetIcon does match that purpose, however it's not a standard WebExtensions API.

[1] Iterating through all existing tabs when the worker wakes up