New official name: `no-window-open-if`.
The pattern will now be matched against all arguments passed
to `window.open()`: all the arguments are joined as a single
space-spearated string, and the result is used as the target
for matching the pattern.
To enable logging, used the extra parameters approach, i.e.
`log, 1`, which should come after the positional arguments
`pattern`, `delay`, and `decoy`.
Added support for extra parameter `reload, 1`. If present,
the scriplet will force a reload of the webpage if the cookie
being set was not already set.
As per feedback from filter list maintainers.
See `managed_storage.json` for available settings. Currently
only `noFiltering` setting is availale.
`noFiltering` is an array of strings, each being a domain for
which no filtering should occur.
Related discussion:
- https://github.com/uBlockOrigin/uBOL-issues/discussions/35
Avoid using updateContentScripts() as it suffers from an unexpected
behavior, causing injected content scripts to lose proper order
at injection time. The order in which content scripts are injected
is key for uBOL content scripts. Potential out of order injection
was causing cosmetic filtering to be broken.
Use actual storage API to persist data across service worker
wake-ups and browser launches. uBOL was trying to avoid using
storage API, at the cost of somewhat hacky code (using DNR API
to persist settings).
Make use of session storage if available, to speed up
initialization of waking up the service worker (which at this
point is necessary to properly implement cosmetic filtering).
Related issues:
- https://github.com/uBlockOrigin/uBOL-issues/issues/5#issuecomment-1575425913
- https://github.com/w3c/webextensions/issues/403
Currently, there is no other way to inject CSS user styles than to
wake up the service worker, so that it can inject the CSS styles
itself using the `scripting.insertCSS()` method.
If ever the MV3 API supports injecting CSS user styles directly
from a content script, uBOL will be back to be fully declarative.
At this point the service worker is very lightweight since the
filtering is completely declarative, so this is not too much of
an issue performance-wise except for the fact that waking up the
service worker for the sole purpose of injecting CSS user styles
and nothing else introduces a pointless overhead.
Hopefully the MV3 API will mature to address such inefficiency.
Specifically, avoid long list of hostnames for the `matches`
property[1] when registering the content scripts, as this was causing
whole browser freeze for long seconds in Chromium-based browsers
(reason unknown).
The content scripts themselves will sort out which cosmetic filters to
apply on which websites.
This change makes it now possible to support annoyances-related lists,
and thus two lists have been added:
- EasyList -- Annoyances
- EasyList -- Cookies
Related issue:
- https://github.com/uBlockOrigin/uBOL-issues/issues/5
These annoyances-related lists contains many thousands of specific
cosmetic filters and as a result, before the above change this was
causing long seconds of whole browser freeze when simply modifying
the blocking mode of a specific site via the slider in the popup
panel.
It is now virtually instantaneous, at the cost of injecting larger
cosmetic filtering-related content scripts (which typically should
be garbage-collected within single-digit milliseconds).
Also, added support for entity-based cosmetic filters. (They were
previously discarded).
---
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/RegisteredContentScript
Source code of scriplets is now fetched directly from uBO
project, so there is no longer the need to keep duplicate
versions of scriplet code.
All scriplet filters are now supported.
Raymond Hill