New advanced setting: `benchmarkDatasetURL`
Default value: `unset`
To specify a URL from where the benchmark dataset will be
fetched. This allows to launch benchmark operations from
within published versions of uBO, rather than from just
a locally built version.
With hindsight, I revised decisions made earlier during
this development cycle:
Un-redirectable scriptlets have been removed from
/web_accessible_resources and instead put in the new
/assets/resources/scriptlets.js, which contains all
scriptlets used for web page injection purpose.
uBO will no longer fetch a remote version of built-in
resources.
Advanced setting `userResourcesLocation` will still be
honoured by uBO, and if set, will be fetched every
time at least one asset is updated.
This is a first step, the ultimate goal is to remove
the need for resources.txt, or at least to reduce to
only hotfixes or for trivial resources targeting very
specific websites.
Most resources will become immutable, i.e. they will
be part of uBO's code base. Advantages include easier
code maintenance (jshint, syntax highlight), and to
make scriptlets more easy to code review by external
parties (for example extension store reviewers).
TODO:
- More scriptlets need to be imported before next
release.
- Need to make legacy versions of uBO use a legacy
version of resources.txt, as all the now obsolete
scriptlets will have to be removed once uBO's
next release become widespread.
- Possibly need to add code to load binary
resources so that they can be injected as
data: URI. So far it's unclear whether this is
really needed. For example, this would be needed
if a xmlhttprequest is redirected to an image
resource.
This works only for platforms supporting the return of
Promise by network listeners, i.e. only Firefox at this
point.
When filter lists are reloaded[1], there is a small
time window in which some network requests which should
have normally been blocked are not being blocked
because the static network filtering engine may not
have yet loaded all the filters in memory
This is now addressed by suspending the network request
handler when filter lists are reloaded -- again, this
works only on supported platforms.
[1] Examples: when a filter list update session
completes; when user filters change, when
adding/removing filter lists.
As seen at:
https://whotracks.me/blog/adblockers_performance_study.html
The requests.json.gz file can be downloaded from:
https://cdn.cliqz.com/adblocking/requests_top500.json.gz
Copy the file into ./tmp/requests.json.gz
If the file is present when you build uBO using `make-[target].sh` from
the shell, the resulting package will contain `./assets/requests.json`,
which will be looked-up by the method below to launch a benchmark
session.
From uBO's dev console, launch the benchmark:
µBlock.staticNetFilteringEngine.benchmark();
The usual browser dev tools can be used to obtain useful profiling
data, i.e. start the profiler, call the benchmark method from the
console, then stop the profiler when it completes.
Keep in mind that the measurements at the blog post above where obtained
with ONLY EasyList. The CPU reportedly used was:
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-6600U+%40+2.60GHz&id=2608
Rename ./tmp/requests.json.gz to something else if you no longer want
./assets/requests.json in the build.
The Promise chain was not properly designed for WASM module
loading. This became apparent when removing WASM modules
from Opera build[1].
The problem was that errors thrown by fetch() -- used to
load WASM modules -- were not properly handled.
[1] Opera refuses updating uBO if there are unrecognized file
types in the package, and `.wasm`/`.wat` files are not
recognized by Opera uploader.
Related issue:
- https://github.com/uBlockOrigin/uBlock-issues/issues/407
Both flavors will be stitched together into a single
`vapi-qebrequest.js` file.
The decision of which flavor to use will be made at runtime,
according to the browser environment.
Related issues:
- https://github.com/uBlockOrigin/uBlock-issues/issues/194
This is a first iteration, which purpose is to merely allow
uBO to load properly. Many things are known to not work,
quite probably due to the early Thunderbird support of the
WebExtensions framework.
Permission which had to be removed:
- contextMenus
Manifest entries which had to be removed:
- commands
- sidebar_action
uBO's webRequest listeners are not being called when loading a
feed item in the preview pane, *except* for resources fetched
from embedded iframes.
uBO appears to function properly when a feed item is opened in
its own tab.
When using paths, platform implementations of setIcon typically
will fetch the resource then convert to image data internally.
It is preferable for uBO to do this conversion itself as it can
be done only once at launch time.
With chromium-based browsers, using image data eliminate the
incessant network traffic to fetch browser icons as reported
in the extension's dev tool, meaning a good chunk of overhead
is eliminated.
Also, use optimal icon sizes, as of now both chromium and firefox
prefers 16px instead of 19px, and 32px instead of 38px.
