trusted-click-element does not support procedural cosmetic filters

[trudnorx]

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

I would like trusted-click-element to be able to use a has-text selector.
This would be a very relevant and useful feature bc many buttons lack an ID, etc and are best selected through this mechanism or similar.

A specific URL where the issue occurs.

-

Steps to Reproduce

Expected behavior

Actual behavior

uBO version

Latest

Browser name and version

Operating System and version

[stephenhawk8054]

@sadtango289 Please report by the button in uBO panel. Don't hijack the thread.

[gorhill]

trusted-click-element is a scriptlet to inject, procedural filters are completely separate, each unaware of the other, by design. I prefer to decline because of the amount of work this would require (keeping in mind all the unknowns performance-wise and more), and given there is no actual real world case provided.

[trudnorx]

@gorhill Here is an use case. trusted-click-element has become increasingly important, used very frequently for a variety of reasons. However, the current targeting mechanism, that finds which element to click, loses specificity because you are not able to specify a precise button text. As I originally stated, many buttons lack an ID and you have to target them by relying on secondary factors. In many cases the most direct and specific way, or even the only truly direct one, to target such buttons would rely on the text. This is 100% a real world phenomenon occurring on many buttons on many of the most visited websites. This is all the worse because of a) changing website layouts, b) unclean HTML code, c) abusive websites using obfuscated and ever-changing HTML code to ram "features" against the users that put their privacy and security at risk.

One is forced to target the button based on not-so-specific secondary factors. This increases the probability of the wrong button ending up clicked, which in the worst case could make something harmful happen to the user. The alternative is that people fear using trusted-click-element due to it not supporting enough specificity, nullifying the increased usefulness of this feature. The ability to target specific button text would be extremely useful, beating even these abusive websites that use obfuscated code and are nevertheless forced to have a consistent button text.

This could also be implemented not by using the has-text filter, but by adding a new argument to trusted-click-element that specifies a button text, and I would consider that to resolve much of the reason I submitted this issue. It's also worth keeping in mind that as filters like has-text gain in usefulness, it would also be useful to be able to use all filters of these kind within any context, not only the one they're available in now, for similar reasons as stated above.

[stephenhawk8054]

actual real world case means at least an exact URL with exact issue you want to resolve that you can't do with other filters.