Skip to content

0.9.9.0
Compare
Choose a tag to compare
@gorhill gorhill released this 13 Jun 19:04
· 10057 commits to master since this release
0.9.9.0
1aa311f

New

UI in the logger to assist in creating static filters.

Related issue: uBlock-LLC/uBlock#68.

c

A new per-site switch to disable remote fonts

c

"Side-effect" is to fix issue #15:

  • Simply add the rule no-remote-fonts: * true to "My rules", and remote fonts from everywhere will be blocked by default -- yet uBlock will still be able to use its FontAwesome font from its package.
  • As a opposed to using a browser setting to disable remote fonts, you can enable remote fonts on a per-site basis -- so disabling remote fonts is no longer an all or nothing choice.

The number of times a page did or did try to download remote fonts appears as a badge aside the switch.

Caveat: Chromium's webRequest API does not specifically report requests of type font, fonts are reported as type other. Whether a request is for a font resource is inferred by uBlock using the "extension" of the path part of a URL. However a URL can be anything really, regardless of request type, so for Chromium-based browsers, uBlock may have to block a font after the request is made, when the response headers are received from the remote server -- as the response headers allow to identify for sure the type of a resource.

Ability to find out from which filter lists a static filter originates:

Related issue: #58.

c

Can be accessed from the logger: if a static filter is present in the 3rd-column of a row, clicking on the cell will show the filter list(s) in which the filter can be found.

There is a resource cost to reverse lookup filter lists from a filter, but this is mitigated by implementing the reverse lookup as a standalone "service", which is launched if and only if an actual reverse lookup is requested.

Since reverse lookup is potentially CPU intensive (depending on number of lists, size of lists), the lookup is performed from within a Worker, i.e. its own dedicated thread:

c
Resource cost while reverse lookup service is alive: 6.5 MB on Nightly. It's because all the stored compiled version of filter lists in use must be kept in live memory to perform the lookup efficiently.

The reverse lookup "service" will shutdown itself after being idle for a set time (currently 11 minutes), so that the extra resources used are freed.

Strict blocking will now show you which filter list(s) caused a document to be blocked:

Related issue: #298.

c

This is accomplished by using the reverse lookup feature described above.

Filter lists with special instructions for proper usage

Related issue: #312.

Some filter lists require extra steps for proper usage. Those filter lists are now identified with a special icon, which links to instructions on how to use the filter list:

c

Changes

Issue #59 was fixed as a side-effect of some specific re-factoring related to how the static filtering engine returns results -- a necessary step toward fixing other future issues. The effect of this specific re-factoring:

  • The logger will now report accurately the static (atomic) filter which affects a network request. For examples:
    • The third-party filter option is now reported if present (it wasn't before).
    • If a filter applies to a specific request type, this is now reported (it wasn't before).
    • If a filter applies to a specific domain, this is now always reported (it wasn't always before).
  • Some overhead removed from the static filtering engine for when the logger is not opened.
    • Previously, uBlock was returning a string representation of a filter in case of match, even if that (inaccurate) string representation was not going to be used in the logger. This does not happen anymore.

Closed as fixed:

Core
Assets 4
Loading