Skip to content

Fix voelkner.de consent#33162

Merged
stephenhawk8054 merged 4 commits into
uBlockOrigin:masterfrom
ryanbr:fdsfsdfdsfds
Jun 4, 2026
Merged

Fix voelkner.de consent#33162
stephenhawk8054 merged 4 commits into
uBlockOrigin:masterfrom
ryanbr:fdsfsdfdsfds

Conversation

@ryanbr

@ryanbr ryanbr commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@ryanbr ryanbr changed the title Fex voelkner.de consent Fix voelkner.de consent Jun 3, 2026
@stephenhawk8054

Copy link
Copy Markdown
Member

vg.no was addressed here: 0dc0d44

Better to address these sites separately, like at #22295

@stephenhawk8054 stephenhawk8054 linked an issue Jun 4, 2026 that may be closed by this pull request
11 tasks
@stephenhawk8054 stephenhawk8054 merged commit 11e8427 into uBlockOrigin:master Jun 4, 2026
@gorhill

gorhill commented Jun 4, 2026

Copy link
Copy Markdown
Member

Yesterday I had tried that sort of filter shortly after my other proposed ones in the other thread:

voelkner.de##+js(trusted-click-element, 'button[data-cookie_consent="0"]')

However I found out that a delay was needed otherwise this doesn't work. Stepping through the code, I see that without delay, the mutation observer somehow is not triggered after the DOM is finally filled with the dialog element.

So I have changed the code to no longer rely on mutation observer but rather on requestIdleCallback to wait for the target element to become part of the DOM. This allows the current case to be fixed without requiring a delay, and maybe this will fix more other such cases.

@stephenhawk8054

stephenhawk8054 commented Jun 4, 2026

Copy link
Copy Markdown
Member

with requiring a delay

You mean "without requiring a delay"?

@gorhill

gorhill commented Jun 4, 2026

Copy link
Copy Markdown
Member

Well, Safari doesn't support requestIdleCallback so I was testing with requestAnimationFrame and the problem still exists there with this method. Investigating further, turns out that without a delay the element is found and clicked too early -- requestIdleCallback was inherently causing a delay to occur so that in the end it worked.

So I am wondering now: should we click only elements which are visible? There is a method to check visibility, so the scriptlet could use this before clicking. Could this cause issues to existing trusted-click-element filters?


I added the when-visible: modifier for selectors: if a selector is prepended with when-visible:, the matching element will be clicked only once it becomes visible. gorhill/uBlock@aa028ea. Example:

voelkner.de##+js(trusted-click-element, 'when-visible:button[data-cookie_consent="0"]')

So this changes nothing for existing trusted-click-element filters.

@stephenhawk8054

Copy link
Copy Markdown
Member

should we click only elements which are visible

There are some cases where the sites hide the reject buttons but we can still click on them. Would this affect these cases?

@gorhill

gorhill commented Jun 4, 2026

Copy link
Copy Markdown
Member

I introduced the prefix when-visible: for when we want to wait for visibility, so all existing filters are unaffected by the addition of this prefix.


The biggest change from the latest commit is that the scriptlet no longer depends on mutation observer to wait for targeted elements to become available, hopefully no regression arise from this change.

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

Successfully merging this pull request may close these issues.

voelkner.de: breakage

3 participants