Proposal: Toggle sets of (custom) filters using dynamic rules

[Atemu]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

I have custom filters that aeld mouse/pointer events to block annoying/distracting interactions such as pop-ups by default and that's been working well. (Thank you for that! uBO is very versatile in this regard.)

Some websites require such events to perform their desired function however. For this purpose, I'd like to disable these aeld filters on only those specific websites via an allow-list. I have not found a way to do that short of editing the custom filter list, reloading and reverting it again (or disabling uBO outright).

The most sensible approach I could come up with from a user's perspective would be to allow assigning names to sets of filters which could then be referenced in place of the type in the dynamic rules system. This way I'd name my set of aeld filters e.g. pointer-events and it'd show up beneath 3p frames in the popup, allowing me to set per-site noops.
(The same principle could also be applied to whole static filter lists.)

I think such a generic system could cover many use-cases or even accessibility needs that people have.

(I have no experience to speak of in web or browser extensions and don't know this codebase, so this might be quite a bit more complex than I imagine. Feel free to dismiss in that case.)

A specific URL where the issue occurs.

n/a

Steps to Reproduce

n/a

Expected behavior

n/a

Troubleshooting information

n/a

[stephenhawk8054]

Dynamic rules are only for quick network blocking/nooping/allowing. They are designed that way, in which you can block/noop/allow requests on the fly. That's the whole principles behind it. They are not for fiddling anything inside websites' contents.

Anyways, feature requests, especially the ones that are asked just for personal usage of very few people and not related to ads/trackers issues, won't be accepted outside regular contributors of the project.

[Atemu]

Dynamic rules are only for quick network blocking/nooping/allowing.

As mentioned, the intention is indeed to quickly allow-list sites to unbreak them when you come across one during regular usage or only want to allow it temporarily; just like with existing dynamic rules.

just for personal usage of very few people and not related to ads/trackers issues

That's fair.

There is also a tracking/fingerprinting aspect to this though as pointer movements, focus changes etc. are extremely characteristic. Disabling such events by default would be a huge boon IMV and is also one of the motivations for me.

This is also relevant for blocking annoyances such as timeout-based popups (don't you want to subscribe to our newsletter? 🙄️) by default-disabling timeout event listeners, as those are sometimes also used for legitimate purposes.

I also don't really see how this kind of functionality would be fundamentally different to e.g. no-cosmetic-filtering, which already implements a kind of filter set toggle that fiddles with website contents. (Other than being quite a bit more generic and flexible but that might also make it quite a bit more complex to implement of course.)

won't be accepted outside regular contributors of the project.

Would you accept a PR If I (or someone else) were to implement this? (In a proper manner.)

[stephenhawk8054]

Cosmetic filtering are just simply CSS. They are not hooking to the JavaScript functions like scriptlets, which is why you can override and un-override without reloading the websites. Any actions hooking JS functions will cause much complexities and overheads than network or CSS, hence they are not for "dynamic" rules. It's exactly how naturally the custom features added to uBOL MV3 goes from network filters -> cosmetic filters -> custom scriptlets (in which the last requires users manually turning on userscript settings inside the browsers).

Would you accept a PR If I (or someone else) were to implement this? (In a proper manner.)

And who will maintain all the code debts and issues with it in the future? gorhill? Or any contributors here?