Related issue:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1652925

Related issue:
- uBlockOrigin/uBlock-issues#1341

Related commit:
- gorhill@a223031

Notably, make `queryprune` option available only
to filter list authors, until there are guards
against bad filters in some future and until the
option syntax and behavior is fully settled.

Instances of `queryprune` in filter lists will be
compiled, however instances of `queryprune` in
_"My filters"_ will be ignored unless users
indicated they are a filter list author.

Fixes uBlockOrigin/uBlock-issues#1337

Related commit:
- gorhill@d8b6b31

Until a fully usable dark theme is available. uBO's
incomplete dark theme can still be forced by setting
advanced setting `uiTheme` to `dark`.

Related commit:
- gorhill@b265f26

Filters which have `domain=` option with an entity
value will no longer be prevented from joining
pre-test buckets.

Related commit:
- gorhill@b265f26

Notably, add clickable link to open the widget
in its own tab. Also, allows the URL to be text-
selected so that it becomes possible to use the
selection in a browser contextual menu's "Open
in a new tab" option.

Some URLs can be quite long, so the div containing
the URL needs to be scrollable if needed.

Related issue:
- uBlockOrigin/uBlock-issues#1345

This reverts commit ab33296.

Related issue:
- uBlockOrigin/uBlock-issues#1349

Related issue:
- uBlockOrigin/uBlock-issues#1293

Related issue:
- uBlockOrigin/uBlock-issues#1346

Additionally, fixed a case of filter list being compiled
twice at subscription time.

Related feedback:
- gorhill@b12e0e0#commitcomment-44309540

As per feedback from filter list maintainers.

Related issue:
- uBlockOrigin/uBlock-issues#1319

Not sure why I set z-index to 0; removed due to mouse
event not reaching the scrollbar.

`about:srcdoc` frames are their own origin, trying to
use the origin of the parent context causes an
exception to be thrown when accessing location.href.

The auto-complete feature in the _"My filters"_ pane will
use hostname/domain from the set of opened tabs to assist
in entering values for `domain=` option. This also works
for the implict `domain=` option ṗrepending static extended
filters.

New filter options
==================

Strict partyness: `1P`, `3P`
----------------------------

The current options 1p/3p are meant to "weakly" match partyness, i.e. a
network request is considered 1st-party to its context as long as both the
context and the request share the same base domain.

The new partyness options are meant to check for strict partyness, i.e. a
network request will be considered 1st-party if and only if both the context
and the request share the same hostname.

For examples:

- context: `www.example.org`
- request: `www.example.org`
- `1p`: yes, `1P`: yes
- `3p`: no,  `3P`: no

- context: `www.example.org`
- request: `subdomain.example.org`
- `1p`: yes, `1P`: no
- `3p`: no,  `3P`: yes

- context: `www.example.org`
- request: `www.example.com`
- `1p`: no, `1P`: no
- `3p`: yes,  `3P`: yes

The strict partyness options will be visually emphasized in the editor so as
to prevent mistakenly using `1P` or `3P` where weak partyness is meant to be
used.

Filter on response headers: `header=`
-------------------------------------

Currently experimental and under evaluation. Disabled by default, enable by
toggling `filterOnHeaders` to `true` in advanced settings.

Ability to filter network requests according to whether a specific response
header is present and whether it matches or does not match a specific value.

For example:

    *$1p,3P,script,header=via:1\.1\s+google

The above filter is meant to block network requests which fullfill all the
following conditions:

- is weakly 1st-party to the context
- is not strictly 1st-party to the context
- is of type `script`
- has a response HTTP header named `via`, which value matches the regular
  expression `1\.1\s+google`.

The matches are always performed in a case-insensitive manner.

The header value is assumed to be a literal regular expression, except for
the following special characters:

- to anchor to start of string, use leading `|`, not `^`
- to anchor to end of string, use trailing `|`, not `$`
- to invert the test, use a leading `!`

To block a network request if it merely contains a specific HTTP header is
just a matter of specifying the header name without a header value:

    *$1p,3P,script,header=via

Generic exception filters can be used to disable specific block `header=`
filters, i.e. `@@*$1p,3P,script,header` will override the block `header=`
filters given as example above.

Dynamic filtering's `allow` rules override block `headers=` filters.

Important: It is key that filter authors use as many narrowing filter options
as possible when using the `header=` option, and the `header=` option should
be used ONLY when other filter options are not sufficient.

More documentation justifying the purpose of `header=` option will be
provided eventually if ever it is decided to move it from experimental to
stable status.

To be decided: to restrict usage of this filter option to only uBO's own
filter lists or "My filters".

Changes
=======

Fine tuning `queryprune=`
-------------------------

The following changes have been implemented:

The special value `*` (i.e. `queryprune=*`) means "remove all query
parameters".

If the `queryprune=` value is made only of alphanumeric characters
(including `_`), the value will be internally converted to regex  equivalent
`^value=`. This ensures a better future compatibility with AdGuard's
`removeparam=`.

If the `queryprune=` value starts with `!`, the test will be inverted. This
can be used to remove all query parameters EXCEPT those who match the
specified value.

Other
-----

The legacy code to test for spurious CSP reports has been removed. This
is no longer an issue ever since uBO redirects to local resources through
web accessible resources.

Notes
=====

The following new and recently added filter options are not compatible with
Chromium's manifest v3 changes:

- `queryprune=`
- `1P`
- `3P`
- `header=`

Related commit:
- gorhill@bde3164

Related issue:
- uBlockOrigin/uBlock-issues#1358

Related issue:
- uBlockOrigin/uBlock-issues#1362

Related commit:
- gorhill@60d5b85

Related issue:
- uBlockOrigin/uBlock-issues#1362

Related issue:
- uBlockOrigin/uBlock-issues#1356

Related commit:
- gorhill@bde3164

It is not possible to achieve perfect compatiblity at this
point, but reasonable compatibility should be achieved for
a majority of instances of `removeparam=`.

Notable differences:
--------------------

uBO always matches in a case insensitive manner, there is
no need to ask for case-insensitivity, and no need to use
uppercase characters in `queryprune=` values.

uBO does not escape special regex characters since the
`queryprune=` values are always assumed to be literal
regex expression (leaving out the documented special
characters). This means `removeparam=` with characters
which are special regex characters won't be properly
translated and are unlikely to work properly in uBO.

For example, the `queryprune` value of a filter such as
`$removeparam=__xts__[0]` internally become the literal
regex `/__xts__[0]/`, and consequently would not match
a query parameter such as `...?__xts__[0]=...`.

Notes:
------

Additionally, for performance reason, when uBO encounter
a pattern-less `queryprune=` (or `removeparam=`) filter,
it will try to extract a valid pattern from the
`queryprune=` value. For instance, the following filter:

    $queryprune=utm_campaign

Will be translated internally into:

    utm_campaign$queryprune=utm_campaign

The logger will reflect this internal translation.

Related issue:
- uBlockOrigin/uBlock-issues#1364

Related issue:
- uBlockOrigin/uBlock-issues#1365

Related issue:
- gorhill#3590

Since the `redirect=` option was refactored into a modifier
filter, presence of a type (`script`, `xhr`, etc.) is no
longer a requirement.

`match-case`
------------

Related issue:
- uBlockOrigin/uAssets#8280 (comment)

The new filter option `match-case` can be used only for
regex-based filters. Using `match-case` with any other
sort of filters will cause uBO to discard the filter.

`redirect=`
-----------

Related issue:
- uBlockOrigin/uBlock-issues#1366

`redirect=` filters with unresolvable resource token at
runtime will be discarded.

Additionally, the implicit priority is now set to 1
(was 0). The idea is to allow custom `redirect=` filters
to be used strictly as fallback `redirect=` filters in case
another `redirect=` filter is not picked up.

For example, one might create a `redirect=click2load.html:0`
filter, to be taken if and only if the blocked resource is
not already being redirected by another "official" filter
in one of the enabled filter lists.

Related issue:
- uBlockOrigin/uBlock-issues#1367

Regression from:
- gorhill@6ac09a2

Need to mind wildcards adjacent to extracted token.

Related discussions:
- uBlockOrigin/uBlock-issues#1356 (comment)
- AdguardTeam/CoreLibs#1384

Changes:

Negation character is `~` (instead of `!`).

Drop special anchor character `|` -- leading `|`
will be supported until no such filter is present
in uBO's own filter lists. For example, instance
of `queryprune=|ad` will have to be replaced with
`queryprune=/^ad/` (or `queryprune=ad` if the name
of the parameter to remove is exactly `ad`).

Align semantic with that of AdGuard's `removeparam=`,
except that specifying multiple `|`-separated names
is not supported.

Related feedback:
- uBlockOrigin/uBlock-issues#1363 (comment)

The header value is no longer implicitly a regex-based literal, but
a plain string against which the header name is compared. The value can
be set to a regex literal by bracing the header value with the usual
forward slashes, `/.../`.

Examples:

    *$1p,strict3p,script,header=via:1.1 google
    *$1p,strict3p,script,header=via:/1\.1\s+google/

The first form will cause a strict comparison with the value of the header
named `via` against the string `1.1 google`.

The second form will cause a regex-based test with the value of the header
named `via` against the regex `/1\.1\s+google/`.

The header value can be prepended with `~` to reverse the comparison:

    *$1p,strict3p,script,header=via:~1.1 google

The header value is optional and may be ommitted to test only for the
presence of a specific header:

    *$1p,strict3p,script,header=via

Related issue:
- gorhill#2283

This is a regression causing the referenced issue to no
longer be fixed. The regression was introduced when the
new static filtering parser code was introduced in version
1.28.0:

https://github.com/gorhill/uBlock/releases/tag/1.28.0

As per agreed upon discussion, `queryprune` now follows
exactly the syntax of AdGuard's `removeparam`.

Related discussion:
- uBlockOrigin/uBlock-issues#1356

Related issue:
- uBlockOrigin/uBlock-issues#760

For the short term, `queryprune` will still interpret a
leading `|` to mean "anchor to start of name", until no
such filters are present in uBO's own filter lists.

All matching `redirect-rule` directives will now be reported
in the logger, instead of just the effective one.

The highest-ranked redirect directive will be the one
effectively used for redirection. This way filter list
authors can see whether a lower priority redirect is
being overriden by a higher priority one.

The default priority has been changed to 10, so as to allow
more leeway to create lower ranked redirect directives.

Additonally, rendering of redirect directives with explicit
priority has been fixed in the logger, they will no longer
be rendered as unknown redirect tokens.

Notably, I finally settled for implicit priority of
0, but now negative priority values are allowed.

Related issue:
- uBlockOrigin/uBlock-issues#1134

Related commit:
- gorhill@daf464b

The condition has been spotted occurring when bringing
up the DOM inspector for a page on which cosmetic filters
are being applied.

Not clear why this happens, but uBO must be ready to
graciously handle such condition.

Related issue:
- uBlockOrigin/uBlock-issues#1375

Related commit:
- gorhill@262a1a0

Regression from:
- gorhill@262a1a0