Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please increase the filter amount limit #88

Open
GreatestFool opened this issue Jul 26, 2022 · 4 comments
Open

Please increase the filter amount limit #88

GreatestFool opened this issue Jul 26, 2022 · 4 comments

Comments

@GreatestFool
Copy link

Only today did it start complaining that I have too many filters, although there are 500, there has been no issues with blocking up to this point. If there is a reason for this change, it'd be nice to know why exactly, but preferably this change can be rolled back or changed to accommodate larger filter lists.

@ray-lothian
Copy link
Owner

Can you share the preferences in JSON format?

@ray-lothian
Copy link
Owner

I need the list to test the performance. The feature releases will use declarativeNetRequest on Firefox and there is a limit here;
https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/#property-MAX_NUMBER_OF_REGEX_RULES

belaviyo added a commit to belaviyo/v3tov2 that referenced this issue Jul 27, 2022
@GreatestFool
Copy link
Author

GreatestFool commented Jul 27, 2022

If you're worried about performance and don't really have time to test extensively or to a degree that you'd prefer, being able to arbitrarily set the MAX_NUMBER_OF_REGEX_RULES in the settings would be nice. Leaving it between a range of 1 to 5000 with a reasonable default is okay, but it'd be nice to have a value to allow infinite. A small warning or similar next to the setting or when exceeding a recommended value can help deter people who don't actually need that many from enabling it.

Preferences

The settings are nothing special. I've removed the blocked sites to keep the file small, because they aren't really necessary here, when it's just a lot of regular blocking. I've removed the GUID too for this upload, even though it's not necessary, in case you're wondering why it is missing.

{
  "blocked": [],
  "close": 0,
  "contextmenu-frame": false,
  "contextmenu-pause": false,
  "contextmenu-resume": true,
  "contextmenu-top": false,
  "crate": 4,
  "css": "",
  "guid": "",
  "initialBlock": true,
  "last-update": 1658852887671,
  "managed.storage.overwrite.on.start": false,
  "map": {},
  "message": "",
  "no-password-on-add": true,
  "redirect": "https://i.redd.it/1wbz4b15vcd31.jpg",
  "reverse": false,
  "schedule": {
    "times": {}
  },
  "schedule-offset": 0,
  "schedules": {},
  "sha256": "",
  "timeout": 60,
  "title": true,
  "wrong": 1
}

@GreatestFool
Copy link
Author

GreatestFool commented Sep 23, 2023

I'm bumping this issue, I have not heard back regarding this. It'd still be preferable to have an arbitrarily set limit, with a warning, or no limit at all and simply warning the user when they exceed a certain amount instead. There is no real performance reason to avoid this, aside from taking the easy way out. A 100 individual filters should make no difference compared to a regex that checks 100 domains and/or urls on certain domains.

Over time users will collect lists that exceed your limit, simply because at a time-scale of years with blocking a site once-in-a-while will grow larger than one otherwise expects.

Please look over this issue again and consider adding functionality for user-set limits.

e: Just a small edit to point something out. Even if you ignore the performance off 100 individual rules vs 100 different ORs in a regex (or in my case, 628), there's the ease-of-use to consider. It's vastly easier to eyeball a list of individual rules versus a (in my case) 7636 character long string.

e2: Just noticed something amusing, which is also another example of the issue of merging rules past a certain point. The string in the browser settings UI is not truncated, and thus leave you having to scroll to the right for however long your string is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants