Investigate support for `popup` filter option

[gorhill]

Currently filters with popup option are discarded when converting filter lists at uBOL build time.

Investigate implementing support for popup filter option, possibly using declarative content scripts.

Internal discussion: https://github.com/uBlockOrigin/uBlock-discussions/discussions/790#discussioncomment-16034415

[gorhill]

I created a content script, injected at document_end time to match the page URL with a list of popup-related domains/regexes.

Then I tried this reproducible case:

• Navigate to https://primevid.click/?api=all#wkn6fr
• Click the play button until "Click to view ads n of 3" appears
• Click "Click to view ads n of 3"
• Result: a popup tab opens, typically to some URL resembling https://flusteredexam.com/bb3KVV0.PN3_pdvtbgmSVDJDZ/DQ0/2vOxD/IL2/NNDNMszXLZTjYi4lM/j-YI0KMyzvcQ -- hostname may vary

If strict-blocking kicks in, the content script is not being injected because the strict-block page is an extension document, while the content script is meant to be injected in https/http pages. Hence the popup won't automatically be closed.

In case strict-blocking doesn't kick in but the document is still blocked, this opens a browser-owned error page, again meaning the content script won't be able to be injected.

Given the above, the following changes in behavior will be made in next release:

Main document will no longer be blocked, only redirected to a strict-block page when there is a match and strict-blocking is enabled. If strict-blocking is not enabled or the page URL does not match a strict-block rule, the popup page won't be prevented from loading. This allows the popup-related content scripts to be injected.

The popup-related content scripts have to execute at document_start because a popup-related page could immediately navigate to another URL when its JS executes. Popup-related content scripts need to execute first to prevent this from happening. The case above does exactly that, and the popup is no longer automatically closed when the popup-related content scripts are executed at document_end or document_idle.

One remaining task to implement is that the popup-related content scripts are not injected when a popup URL is strict-blocked -- meaning strict-blocked URLs which match a popup filter will not be auto-closed -- this is actually the current behavior. One solution is to have the strict-blocked page dynamically import and execute popup filtering code. Given the behavior would be the same as the current one, I may decide to address this in a future release.

All popup filters which require to evaluate the context (third-party, domain=) are discarded because the context can't be evaluated in a content script.