trusted-click-element activates in non-intended pages (iframe issue)

[peace2000]

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

Currently, countless webpages use GPDR consent window that they load from cdn.privacy-mgmt.com by using an iframe.

This means that no matter what is the parent page, the filter to click the GDPR window must use cdn.privacy-mgmt.com in the domain part of the rule:

cdn.privacy-mgmt.com##+js(trusted-click-element, button[title="Reject All"])

This means that everytime a page uses that iframe, numerous filters - that are not designed for the current parent page - will activate:

This is probably not a good thing as this is a trusted scriptlet - it's unclear which rule will actually click the window, and the scriptlet will activate multiple times in vain.

I think we should be able and we should target the iframe based on its parent context.

A specific URL where the issue occurs.

https://www.businessinsider.com/starbucks-to-close-1-of-stores-in-strategic-shift-2025-9

Steps to Reproduce

1. Use uBO cookies list
2. Go to: https://www.businessinsider.com/starbucks-to-close-1-of-stores-in-strategic-shift-2025-9
3. Check the logger

Expected behavior

No wrong and unnecessary filters would activate.

Actual behavior

Wrong and unnecessary filters do activate.

uBO version

1.66.1b0

Browser name and version

FF 143.0.1

Operating System and version

Win 10

[peace2000]

Maybe this could be solved by adding a vararg? Such as:

context, businessinsider.com

context, 'businessinsider.com, example.com'

This would make the filter to only activate if businessinsider.com (or another domain in the list) is the parent context?

[krystian3w]

Apparently, support for frames has been added via: gorhill/uBlock@a483f7955f

businessinsider.com>>##+js(trusted-click-element, button[title="Reject All"])

However, the filter compatibility tester indicates that it does not work with MV2 (even if it is for private use, I have some anti geo location global scriptlets that I exclude from the logger using *>>#@# in iframes (I think I see a little less of it being forced into iframes)). The error in the tester may be due to my software.

---

Perhaps the parameters in the frame reveal the domain name and you could use something like:

cdn.privacy-mgmt.com/*1218008##+js(trusted-click-element, button[title="Reject All"])

and gorhill wrote something somewhere that the scriptlet mechanism may not be fully ready for it (there may be some errors).

---

Additionally, the domain has geo locks and in Poland it redirects to the Polish version with a 404 error (supposedly you would have to add the ?IR=C to homepage link and later opens article).

[stephenhawk8054]

We already have >>+js() for injecting scriptlets to the inside iframe of a site.

However, I thought the cdn.privacy-mgmt.com filters are also for using in multiple sites that have the same elements without adding each site manually?

[peace2000]

Hmm, this actually seems to work indeed:

businessinsider.com>>##+js(trusted-click-element, button[title="Reject All"])

Didn't realize we have that option as well.

But what it comes to cdn.privacy-mgmt.com, we currently have filters that click "agree" and filters that click "disagee". These are contradicting each other so these cannot be used universally.

[krystian3w]

To maintain backward compatibility with uBo 1.53.0-1.62.0, one would have to analyze the frame code attributes or the layout of the elements between all notifications of this type of pop-up or bar (I would limit this manual maintenance to real cases of clicking reject instead of the required accept something).

Rewriting to >>## (or handling a path with a strange frame ID - without obvious problems due different code for scriptlets) will cut off people who don't want to update uBo to version 1.63.0+ (if the filters have a comment above, you can try to write a script that replaces domains and remembers add >>).

[stephenhawk8054]

Hmm... If there are conflicting elements to click, it's better to use >>+js().

[gorhill]

The problem with >>## for scriptlets is the cache issue also affecting path- or regex-based contexts. This can be seen at https://ublockorigin.github.io/uBOL-home/tests/test-filters.html: the test pass with uBO Lite, but not with uBO (because the scriptlet is cached). Hmm the cache issue is a problem only when the scriptlet in injected in same domain, which is what happens in test page. So yes, it should work for the issue reported here. But then the scriplet will be injected in all subframes on a given site, not sure it's a good solution long term.

[stephenhawk8054]

But then the scriplet will be injected in all subframes on a given site, not sure it's a good solution long term.

Usually we can use

example.com>>,~cloudflare.com##+js()

to exclude an iframe.

But if there's a syntax to signal uBO to only inject an exact iframe domain and ignore other iframes domains, it might be better?

Something like

example.com>>iframe.com##+js()

?

[u-RraaLL]

cdn.privacy-mgmt.com/*1218008##+js

IIRC /path didn't work for limiting scriptlets.

[peace2000]

example.com>>iframe.com##+js()

This sounds better proposal than mine - and would be useful generically for all scriptlets.

Though if we want to combine many domains together where we inject into an iframe, it wouldn't look elegant:

aamulehti.fi>>cdn.privacy-mgmt.com,etlehti.fi>>cdn.privacy-mgmt.com,gloria.fi>>cdn.privacy-mgmt.com,hs.fi>>cdn.privacy-mgmt.com,hyvaterveys.fi>>cdn.privacy-mgmt.com,is.fi>>cdn.privacy-mgmt.com,jamsanseutu.fi>>cdn.privacy-mgmt.com,janakkalansanomat.fi>>cdn.privacy-mgmt.com,kankaanpaanseutu.fi>>cdn.privacy-mgmt.com,kmvlehti.fi>>cdn.privacy-mgmt.com,kodinkuvalehti.fi>>cdn.privacy-mgmt.com,merikarvialehti.fi>>cdn.privacy-mgmt.com,nokianuutiset.fi>>cdn.privacy-mgmt.com,pelikone.fi>>cdn.privacy-mgmt.com,rannikkoseutu.fi>>cdn.privacy-mgmt.com,ruutu.fi>>cdn.privacy-mgmt.com,satakunnankansa.fi>>cdn.privacy-mgmt.com,soppa365.fi>>cdn.privacy-mgmt.com,suurkeuruu.fi>>cdn.privacy-mgmt.com,sydansatakunta.fi>>cdn.privacy-mgmt.com,tyrvaansanomat.fi>>cdn.privacy-mgmt.com,valkeakoskensanomat.fi>>cdn.privacy-mgmt.com,vauva.fi>>cdn.privacy-mgmt.com##+js()

These are Finnish sites, owned by the same company that all use the same GDPR iframe.

Unless we assume that all domains in the same list inject into the same iframe (which is anyway the most probable case):

aamulehti.fi,etlehti.fi,gloria.fi,hs.fi,hyvaterveys.fi,is.fi,jamsanseutu.fi,janakkalansanomat.fi,kankaanpaanseutu.fi,kmvlehti.fi,kodinkuvalehti.fi,merikarvialehti.fi,nokianuutiset.fi,pelikone.fi,rannikkoseutu.fi,ruutu.fi,satakunnankansa.fi,soppa365.fi,suurkeuruu.fi,sydansatakunta.fi,tyrvaansanomat.fi,valkeakoskensanomat.fi,vauva.fi>>cdn.privacy-mgmt.com##+js()

[gorhill]

Any other content blockers have something to deal with such case?

[stephenhawk8054]

I don't think there are any.

I'm a bit surprised we have that many scriptlets for cdn.privacy-mgmt.com (31 scriptlets). Some sites might just need blocking the cookies instead of clicking I think.

[krystian3w]

When blocking in incorrect/bad way, embedded videos and social media were probably thrown out.

Unless you have experience using, for example, noop.js:

/wrapperMessagingWithoutDetection.js$script,xhr,from=...,redirect=noop.js

I don't think anyone made a elegant surrogate file, AdGuard only made it for Didomi^{1 2}. The problem with continuing surrogates may be the personalization of these “CMP” systems.

Footnotes

1. https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-redirects.md#-%EF%B8%8F-didomi-loader ↩

2. https://github.com/AdguardTeam/Scriptlets/blob/master/wiki/about-scriptlets.md#-%EF%B8%8F-didomi-loader ↩