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
Add a list for cookies warnings #5
Comments
Also the list for I dont care about cookies, Easylist cookie, and also a few of the lists for social stuff. |
I would probably go with EasyList Cookie which is already a stock filter list in uBO. However at this point uBOL does not supports generic cosmetic filtering, and EasyList Cookie has nearly 17K of generic cosmetic filters, so it won't be very useful until (and if) generic cosmetic filters are supported.
MV3 limits the number of enabled rulesets at 10, so including more than one list for cookies won't work. For those who want more than what can be achieved with the MV3 limitations, uBOL is not for them. |
It certainly is not obsolete, it last updated today:
EasyList server has had issue recently, maybe these are still is ongoing. Try downloading the one at https://secure.fanboy.co.nz/. Also, be sure your own uBO configuration is not causing the fetch to fail -- use the logger with the All entry selected. |
You are right,there is a heavy storm here,I had network problems. |
That is for enabled rulesets so as long as there's a room to the total rulesets limit (50), including AG Cookie and let user to choose which one to enable should be possible. But I guess you wanna realize the idea of simple filter selection discussed in past e.g. just choosing "Cookie" category automatically enables ELC. (As a side note, AGC relies less on generic cosmetic filters.) |
Hopefully activating the community-wide list ELC by default will force a better fix for bugged heritage filters (faster than 60 days to investigate). |
Any news on this issue, will a list be implemented? |
Declining for now, I may re-evaluate in the future as the MV3 API mature. Making Easylist Cookies available led to undue delay when changing filtering mode, due to some unidentified performance issue with Probably best for now to rely on a specialized extension for the task of dealing with cookie warnings. |
Specifically, avoid long list of hostnames for the `matches` property[1] when registering the content scripts, as this was causing whole browser freeze for long seconds in Chromium-based browsers (reason unknown). The content scripts themselves will sort out which cosmetic filters to apply on which websites. This change makes it now possible to support annoyances-related lists, and thus two lists have been added: - EasyList -- Annoyances - EasyList -- Cookies Related issue: - uBlockOrigin/uBOL-home#5 These annoyances-related lists contains many thousands of specific cosmetic filters and as a result, before the above change this was causing long seconds of whole browser freeze when simply modifying the blocking mode of a specific site via the slider in the popup panel. It is now virtually instantaneous, at the cost of injecting larger cosmetic filtering-related content scripts (which typically should be garbage-collected within single-digit milliseconds). Also, added support for entity-based cosmetic filters. (They were previously discarded). --- [1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/RegisteredContentScript
The element has an inline style, though I am pretty sure this was working before (time passes, might be wrong), it seems Chromium may have changed its implementation of CSS layer such that inline style is back to having precedence to the CSS layer injected by uBO. The proper solution for uBO (to stay entirely declarative) is Proposal: Declarative Cosmetic Rules. |
Related issues: - uBlockOrigin/uBOL-home#5 (comment) - w3c/webextensions#403 Currently, there is no other way to inject CSS user styles than to wake up the service worker, so that it can inject the CSS styles itself using the `scripting.insertCSS()` method. If ever the MV3 API supports injecting CSS user styles directly from a content script, uBOL will be back to be fully declarative. At this point the service worker is very lightweight since the filtering is completely declarative, so this is not too much of an issue performance-wise except for the fact that waking up the service worker for the sole purpose of injecting CSS user styles and nothing else introduces a pointless overhead. Hopefully the MV3 API will mature to address such inefficiency.
I note that this functionality has been implemented. It is still required to consider user input of custom rules (consent/block) that can solve some problematic websites. Which are not solved only by the default filter lists. |
That won't be part of uBO Lite, otherwise it's not going to be Lite anymore. For this sort of functionality, that is uBO itself. There is no point using the Lite version if you want everything uBO itself already has. |
Is it possible to at least consider some exceptions to the default filters? Even with uBlock Origin it is quite difficult for the average user to resolve some problematic websites with cookie consent. |
What does that mean in practice? Not sure I understand what you mean by "exceptions" concretely. |
But chrome will eventually say basta to MV2 and uBo will end for it if only in e.g. 2030 as they will find that 2/3 of MV2 postlats will no longer be able to be implemented in MV3 anyway. I doubt that then suddenly 90% of Chrome users will jump to Brave/Vivalidi/Opera or Firefox in e.g. 2030 even if you write from 200 tweets about migration. |
Check out this website: https://ita.xhamster.com/photos With full filtering no cookie warning but missing sidebar on right to scroll down the page: https://github.com/uBlockOrigin/uBOL-issues/assets/44166263/1bb26ef0-ddf3-48c8-8a19-4554e6fe0344 With optimal filtering there is cookie warning you can reject cookies and then the website is fully usable: https://github.com/uBlockOrigin/uBOL-issues/assets/44166263/587399e7-092a-4f5c-9ff3-9268346ae2d8 |
We have file to repair bugs specific for uBo Lite only: https://github.com/uBlockOrigin/uAssets/blob/master/filters/ubol-filters.txt So stock bugs can be addressed their. |
I get the same issue in uBO, it's a filter issue, and should be reported like any other filter issue in uBO. cc @ryanbr, With EasyList -- Cookie Notices, need:
|
I can reproduce with uBO 1.50.0 VPN(Netherlands), Google Chrome. |
I can put this rule in UBO. Keep in mind that there will always be websites with similar problems. P.S. |
If less people report, lists don't improve and will cause more problems. User with an ability to fix problems simply should report, which is a trivial contribution virtually everyone can do. |
Trivial? AdguardTeam/AdguardFilters#152486 Many users let it go,and they do well. |
Try this website that I have already reported: |
Very trivial compared to that list authors, many of them being volunteers and having real job and life, spend hours nealy everyday for others' sake. |
This comment was marked as off-topic.
This comment was marked as off-topic.
≈If uBo Lite never gets a field for custom rules or filters lists then probably Chrome (Not Brave/Vivaldi/Opera) users in ≈2030 will be gobbled up by AdGuard MV3 or they will fall back on AdBlock/Adblock Plus if porting uBO MV2 will continue to be impossible. |
Import country flag-related code from uBO. Switch to AdGuard annoyance-related lists, as this solves uBlockOrigin/uBOL-home#5 (comment)
UBO Lite v.0.1.22.9305
Extended filtering enabled.
Please add rules for cookies warnings.
The list "AdGuard Cookie Notices filter"
https://filters.adtidy.org/windows/filters/18.txt
at least in UBO, resolves almost all the notices attached in the screenshots.
TH.
The text was updated successfully, but these errors were encountered: