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

[garry-ut99]

I would like trusted-click-element to be able to use a has-text selector.

Related issue on AdGuard Scriptlets issue tracker:

• Improve 'trusted-click-element' — add an ability to click on an element containing a given text AdguardTeam/Scriptlets#409

[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.

[garry-ut99]

It has been implemented in AdGuard AdguardTeam/Scriptlets@e9343fd 3 days after it was declined here in uBO repo #3242 (comment).

Looking at the websites provided in the AG's corresponding issue:

• they are already covered in uBO by trusted-set-cookie scriptlets
• also if anyone would ever want to cover them with trusted-click-element,
  a normal cosmetic filter is sufficient to target the "Accept" button: audioteka.com,jastrzabpost.pl,deliciousmagazine.pl,finansowysupermarket.pl,genialne.pl,pysznosci.pl,nocowanie.pl##+js(trusted-click-element, div + div > div > button:not([type]) + button:not([type]), , 1000), however (like most likely trudnorx already mentioned):
  • it's undetermined how long such a selector would last, given dom tree on such websites is randomly generated amd might change quite often
  • there is also a risk, that such a selector might accidentaly click wrong (other) buttons on a site

Anyway, at least 2 different already existing solutions can fix the current websites provided in AG's corressponding thread, means there doesn't seem to be an urgent need to implement procedural cosmetic filters in trusted-click-element to solve the provided cases, hence maybe we should need to wait for more "actual real world cases". Of course maybe AG devs already found other cases, or wanted to implement it just in case or for convenience for filter creators, but the fact that they did, does not necessarily mean that the uBO must also do the same, as not every creator has the time and will to spent time on additional features. Curious what AdamWr and Sergey-Lyapin (and other people) think about it in general, and whether can anybody provide more "actual real world cases" of websites which require to be fixed by trusted-click-element + a procedural cosmetic selector. As for me, currently I'm not sure (means I'm neutral) as to whether to implement or not, the requested feature, but I agree that more "actual real world cases" are welcome to be provided before implementing anything.