Example of how to un-break a site using the dynamic filtering pane
Real, concrete case: issue #1323, also reported on ABP forum:
On money.cnn.com, the comments section is being blocked by a filter
list blocking rule. I would appreciate it if someone could suggest an
exception rule that works in Adblock Plus
From what I gathered, the user had Fanboy’s Annoyance List enabled. With ABP, users are told to use the Blockable items pane to un-break pages broken by one or more static filters, by disabling one or more filters.
In uBlock Origin ("uBO"), it is not possible to disable specific static filters, un-breaking pages is done in different ways: In uBO one does not disable a static filter, one overrides a static filter, and this can be done on a per-site basis. I will illustrate how to do it here using the dynamic filtering pane -- this is the easiest way.
The page which was reportedly broken would not properly render comments:
uBO's popup panel reports that 30 network requests were blocked on the page:
You can fix yourself the issue, and at the same time contribute some investigation work to help narrow the cause of why the page is broken -- the comments section in the current case.
First, enable the "I am an advanced user" mode in the dashboard:
This will give you access to the dynamic filtering pane in the popup panel. By default, there are no rules present in the dynamic filtering pane, which means it does not affect at all what is blocked/allowed:
You can see a list of domain names, with each domain name followed by two cells: the first one is for global rules, the second one is for local rules. For the current case, we will only care about local rules. Local rules are those which apply only to the current site , and we are only interested in un-breaking the current site. The cells for the local rules show whether network requests were allowed/blocked using pluses/minuses.
Now if you scroll down the list of domains, you can see a lot of network requests were blocked, and surely one of the blocked network requests is responsible to cause the comments section from not being rendered.
At this point, there is no magick trick to know beforehand which domain(s) is responsible for making the comments appear properly -- a trial and error approach must be used. Experience helps. For example in the current case, one may notice that network requests to
s3.amazonaws.com were blocked, and an experienced user may consider this anomalous.
In such case, it's worth to try to bypass whatever static block filters blocked the network requests to
The picture above shows a local
allow rule being set for
s3.amazonaws.com. "Local" here means the rule will apply only for the current site (
If you hover the mouse pointer over the local rule cell for
s3.amazonaws.com, you will see that you can set one of three rules:
block. Rules in the dynamic filtering pane always override static filters in effect for a given domain.
allow: always allow network requests, disregard all block static filters (green).
noop: ignore for now -- this belongs to another topic (gray).
block: always block network requests, disregard all exception static filters (red).
Reloading the page with the newly created
allow rule for
s3.amazonaws.com will show that the comments section and other parts on the page now render properly:
This is an example of how you can un-break a site yourself using point-and-click in uBO's popup panel (and trial-error until you find the proper rule). Things to keep in mind:
All rules you set in the dynamic filtering pane are temporary by default:
- You can erase all temporary rules currently set in the pane using the eraser icon.
- You can persist the temporary rules currently set in the pane using the padlock.
The rules being temporary by default is very convenient when trying to find out which set of rules un-break a site, you can commit the proper rules once you find out what works.
Once you succeed in un-breaking a site, you can report the issue to the filter list maintainers that a site was broken -- so that the fix can benefit everybody. In such case it is useful to report:
- A specific URL where the breakage can be seen (
- A description of what is broken ("comments are not rendered").
- The filter lists in use ("EasyList, EasyPrivacy, Fanboy’s Annoyance List, etc.)
- How you fixed the issue ("allowing network request to
s3.amazonaws.com fixed the issue")
It is possible to find out exactly which filter(s) in which filter list(s) was causing the breakage, but this is for another topic.