Replies: 4 comments 2 replies
|
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. |
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.
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.
Would you accept a PR If I (or someone else) were to implement this? (In a proper manner.) |
|
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).
And who will maintain all the code debts and issues with it in the future? gorhill? Or any contributors here? |
|
Is there perhaps another way that would allow toggling filter rules in a selective manner that I have missed? It doesn't have to be seamless or wired up into UI or anything fancy. I just need a way to disable multiple custom filters on some sites only; without also disabling them on all other sites. Disabling all custom filters on some sites only would also work for me. |
Uh oh!
There was an error while loading. Please reload this page.
Prerequisites
I tried to reproduce the issue when...
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-eventsand 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/aSteps to Reproduce
n/a
Expected behavior
n/a
Troubleshooting information
All reactions