Repository navigation
Cosmetic filtering issue with Shadow DOM/tree/root #803
Description
Details
Prerequisites
- I verified that this is not a filter issue
- Filter issues MUST be reported at filter issue tracker
- This is not a support issue or a question
- Support issues and questions are handled at /r/uBlockOrigin
- I performed a cursory search of the issue tracker to avoid opening a duplicate issue
- Your issue may already be reported.
- I tried to reproduce the issue when...
- uBlock Origin is the only extension
- uBlock Origin with default lists/settings
- using a new, unmodified browser profile
- I am running the latest version of uBlock Origin
- I checked the documentation to understand that the issue I report is not a normal behavior
Description
- Generic cosmetic filters don't hide nodes in Shadow DOM. Probably not injected to the page because nodes "in shadow" are not detected.
- Related issue a general filter ###euConsent added easylist/easylist#4232
- This works in ABP/AdBlock, Chrome 78 (Probably because all filters are injected?).
- Specific filters works, but are not logged.
- This does not work in ABP/AdBlock.
A specific URL where the issue occurs
https://www.virustotal.com/gui/home/upload
Steps to Reproduce
"Generic" case:
- Add
###euConsentto My filters - Open linked VirusTotal page
"Specific" case:
- Add
virustotal.com###euConsentto My filters - Open linked VirusTotal page
Expected behavior:
Cookie notice on the bottom should be hidden with generic filter. Filter should be logged.
Actual behavior:
Notice is hidden only by specific filter. No DOM filters are logged.
Your environment
- uBlock Origin version: 1.23 on Chrome, 1.24.3b1 on Nightly, 1.24 on 70.0.1 Fx
- Browser Name and version:
- Operating System and version: Manjaro KDE
@krystian3w, it's side effect of uBO performance/memory optimizations. ABP injects all cosmetic filters unconditionally (AFAIK). uBO injects only specific filters. For generic filters, DOM is scanned and only matching ones are injected. Here Shadow DOM is interfering.
Reacted by Marek33
Activity
gorhill commentedon Nov 30, 2019
Well just to be clear, uBO will never be converted to inject minimum of 20K+ CSS rules in every page and every frame of every page. So if a specific filter is the only solution then the resolution is "by design".
krystian3w commentedon Nov 30, 2019
uBlock-user commentedon Nov 30, 2019
That CSS selector will only be present in the DOM if you connect via EU IP, do you have one that is present for all ?Nevermind it's present in the DOM on my end too.
address uBlockOrigin/uBlock-issues#803
gorhill commentedon Nov 30, 2019
I am not in a position to check myself... Is this Shadow DOM v1 or v2?
uBlock-user commentedon Nov 30, 2019
Yes picker cannot dig on that page either beyond
vt-virustotal-appuBlock-user commentedon Nov 30, 2019
###shareis shown in the logger if added.uBlock-user commentedon Nov 30, 2019
document.querySelector('#euConsent')returnsnull, probably because it's inside the shadowDOM.gorhill commentedon Nov 30, 2019
One solution I can think of is to make use of ABP's semantic,
#?#, in which case uBO would put the cosmetic filter in the highly generic bin and thus would inject it unconditionally on each page/frame. Of course, not to be abused if we go down that route.gorhill commentedon Nov 30, 2019
Yes.
gorhill commentedon Nov 30, 2019
[oops, finger twitched and closed by mistake]
I don't understand your argument. If indeed
#euConsentbecome widespread and part of Shadow DOM (maybe by mean of JS library), how is#?##euConsentnot useful? Yes, it needs to be revisited but it allows to no longer hunt for where it's used in order to keep track of specific sites using it.11 remaining items
gorhill commentedon Feb 16, 2020
uBO already injects over 750+ selectors unconditionally on every page with default configuration1 -- the "highly generic ones" -- out of a total of nearly 21,000 cosmetic filters.
The change here just allows to explicitly force such unconditional injection for some filters which must be injected everywhere but yet can't be injected conditionally through the DOM surveyor.
I expect filter list authors will use the new feature intelligently, the same way the use of regex-based network filters are discouraged, yet they are not forbidden and filter list authors know that they should be used only when there is no other solution. Same approach applies here -- though regex-based network filters is a very bad comparison performance-wise, unconditionally injecting extra CSS selectors should be considered a no-op).
Also I will likely consider #821 to be solved by the solution implemented here.
[1] 1,400+ with Fanboy Social enabled out of a total of 32,600+.
uBlock-user commentedon Feb 16, 2020
Still we would have some control if it was specific to a hostname instead of getting applied on every website regardless of whether the element is present in the DOM or not.
gorhill commentedon Feb 16, 2020
Generic filters which apply everywhere are already supported and unconditional injection is already occurring. There is no good rational reason to worry about the change here. I will leave it at that, I can't prevent people from being unduly anxious about non-issues, I have no control over that.
krystian3w commentedon Feb 16, 2020
No visible in logger (on table)? No everyone use dom tree debugger "
</>".gorhill commentedon Feb 16, 2020
Point 2 is "wontfix" -- this would require to find all nodes with a shadow DOM (which requires traversing all nodes -- there is no native function to get all shadow DOM nodes), then search independently for a match in all these nodes, along with installing a mutation observer for each of those nodes to find out changes withing the shadow DOMs. I decline to make the code more complex than it already is.
uBlock-user commentedon Feb 16, 2020
@gwarser It was about
*##.selector, it can't be made specific. You can disable that filter at specific sites at best.h1z1 commentedon Apr 7, 2020
FWIW you can add pornhub to the list. They have an annoying banner that cannot afaik be blocked because it uses a shadow root.
If you're not getting it the banner itself is random. It was for corvid. Probably spent more time then was healthy trying to block it but I was curious wtf they were doing.
krystian3w commentedon May 25, 2020
ghidecan break:this is good behavior?
in legacy try:
@@*$generichidehub.lumenfield.work,##.selectorgorhill commentedon May 26, 2020
Not sure. I lean toward yes. Is this an issue in a list?
krystian3w commentedon Feb 4, 2023
IMO possible revert uBlockOrigin/uAssets@0d78532 due easylist/easylist@d3530c0
mapx- commentedon Feb 4, 2023
uBlockOrigin/uAssets@8714e19
Add support for "specific-generic" cosmetic filters