$popup does not work

[dimisa-RUAdList]

Prerequisites

• [X] I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• [X] This is not a support issue or a question
• [X] I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• [X] The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• [X] I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• [X] uBO is the only extension
• [X] uBO with default lists/settings
• [X] using a new, unmodified browser profile

Description

$popup does not work

A specific URL where the issue occurs

https://trashbox.ru/link/2021-10-26-rawdraw

Steps to Reproduce

1. Add to "My Filters" trashbox.ru#@#a[href*="://trashbox.ru/r.php?"]
2. Open https://trashbox.ru/link/2021-10-26-rawdraw
3. Click on the banner - https://i.imgur.com/KGMNLFv.jpg

Expected behavior

The popup should be blocked by the rule ||trashbox.ru/r.php?$popup, preventing the click on the advertising link.

Actual behavior

There is a transition to the advertising link.

uBlock Origin version

uBlock Origin development build 1.38.7b9 (default + RUS: RU AdList)

Browser name and version

Google Chrome 95.0.4638.54

Operating System and version

Windows 7

[gorhill]

Add to "My Filters" trashbox.ru##a[href*="://trashbox.ru/r.php?"]

You probably meant trashbox.ru#@#a[href*="://trashbox.ru/r.php?"]?

The popup is not closed because the destination is not blocked as a popup, you need:

||treolan.ru^$popup

Your popup filter ||trashbox.ru/r.php?$popup does not work because it's a legitimate link, the tab which opens is https://trashbox.ru/link/2021-10-26-rawdraw, which is the exact link clicked by the user.

[dimisa-RUAdList]

Yes, of course I meant trashbox.ru#@#a[href*="://trashbox.ru/r.php?"]

The fact is, when using Adblock Plus, I observe different behavior and the rule ||trashbox.ru/r.php?$popup prevents following the link.

[gorhill]

The current behavior was not decided considering ABP, it was chosen according to the number of false positives being reported, and was fine tuned with https://github.com/gorhill/uBlock/issues/2919.

A common issue with popup filters was the regular instances of false positives. The chosen behavior is that if the user click a link and a new tab open as a result which matches exactly the clicked link, the navigation is deemed legitimate and won't be filtered. There is no surprise in such case, and this took care of a lot of false positives.

However, I realize that in the current case, the legitimate navigation redirects immediately to a URL which is unrelated to the original link, this kind of work against the link being legitimate. I need to think about what could be done in such case without bringing back instances of false positives like in the past.

[gorhill]

Trying to further fine tune the current heuristic does not work, it's just going to create more quirks.

What works well though is leveraging the important option:

||trashbox.ru/r.php?$popup,important

In such case, uBO could bypass the assumption that the link clicked is trusted because it caused a navigation to a new tab which URL matches that of the clicked link.

[dimisa-RUAdList]

Oh, this will require creating (for uBO) a new section of pop-up rules with the "important" option in each filter, since Adblock Plus does not understand this option.

[gorhill]

since Adblock Plus does not understand this option

Does it just ignore the important option or does it completely reject filters with important option? I looked at your list and I do see you have filters with important option.

[dimisa-RUAdList]

I created a separate version RU AdList for uBO. It differs in additional files that contain scriptlet-rules and rules for embedding styles.

This is where the rules with the "important" option meet: https://easylist-downloads.adblockplus.org/advblock+cssfixes.txt

This is not the case in the regular version: https://easylist-downloads.adblockplus.org/advblock.txt

It will be difficult to add the "important" option for pop-up rules to all filters, including EasyList, in order to ensure their performance in uBO.

The fact is that Adblock Plus does not know how to ignore unknown rules. Instead, it completely disables all rules of the type that are similar to the detected unknown rule on the domain. For example, adding rule example.com##+js(abort-on-property-read, banner) to filters will completely disable all hiding rules on the domain example.com.

[gorhill]

It will be difficult to add the "important" option for pop-up rules to all filters, including EasyList, in order to ensure their performance in uBO.

You do not have to add it to all popup filters, just for those for which the current heuristic is an actual issue. Even the case here is not a realistic one, I had to create an exception filter not normally present to let an ad through, and required that I click on the ad. I would like to know of actual cases in the real world where the current heuristic is an issue.

I can't go back on the current heuristic, there were regular reports of unduly closed tab after clicking legitimate links, and after years of using the current heuristic, this was a good improvement as witnessed by the (lack of) issues filed regarding false positive with popup filters.

[dimisa-RUAdList]

We never know in advance exactly where we need to add "important". And the very principle of the need for such an addition makes debugging difficult, since you must always keep in mind that the behavior ABP and uBO is different. Ultimately, this leads to filters fragmentation.

The current heuristic to allow ad link click only because the click is direct seems dubious to me.

I carefully studied https://github.com/gorhill/uBlock/issues/2919 and came to the conclusion that the described false positives needed to be corrected in the filters.

For example: ||iqoption.com/land/$third-party,popup > ||iqoption.com/land/$third-party,popup,domain=~iqoption.com or ||iqoption.com/land/$third-party,popup,domain=~affiliate.iqoption.com

Etc

[gorhill]

came to the conclusion that the described false positives needed to be corrected in the filters.

The issue I linked to has also related issues linked to it, for example https://github.com/uBlockOrigin/uAssets/issues/720, and in the comments other contributors have a differing opinion. I agreed with them, hence why the current heuristic. This was not only false positives with filters, but also false positive with the no-popups switch. Going back on that would be a regression in uBO.

---

My proposed solution is to leverage important option, I am willing to implement support for this, but if you do not want the burden of having to create special filters for the apparently somewhat rare instance they might be needed, we will just create those filters in uBO's own lists.

[dimisa-RUAdList]

As far as I can see, cases of false positives are of venerable age and belong to the period when the authors of EasyList and regional filters did not practice debugging rules in uBO. Now the situation has changed and this is what most filter authors do.

Of course, you can do as you see fit, but the current heuristic changes the behavior of uBO compared to Adblock Plus and this forces the authors of all filters to always keep this in mind and perform separate checks that take this feature into account.

[gorhill]

It's difficult for me to make changes to the current behavior without seeing actual, real filter issue cases to convince me that the actual behavior must be changed -- the one you provide is artificial, it's not going to happen in the real world.

[dimisa-RUAdList]

Okay, do as you see fit. If real cases appear, it will be possible to return to this later.

[Yuki2718]

Is a popup filter still needed when cosmetic filter already have done the job?

[dimisa-RUAdList]

There is no need. But the current heuristic will disable pop-up blocking in cases where the advertising link is explicitly specified. For example, when branding the background.

[Yuki2718]

Also transparent link to trick user is common, but they should be addressed first by either cosmetic filter or scriptlet, shouldn't they?

[dimisa-RUAdList]

Yes, exactly.

[uBlock-user]

We usually fix popups in uBO with ##+js(nowoif), does it work for this case ?

[gorhill]

does it work for this case ?

You don't need to do anything for the case provided here, you have to disable a cosmetic filter and click on an ad for it to happen -- something nobody is going to do.

[uBlock-user]

click on an ad for it to happen

If I have to make an ad, which is hidden already, reappear and then click on it just to prove a point, seems not worth the time.

[Yuki2718]

I personally feel the difference btwn ABP & uBO here would hardly be a matter at least in terms of false negative. OTOH the ABP's way of $popup can really be a problem, a worse case of the click-through issue where average user has no chance to choose. Hmm, I certainly saw such a case - popup (kinda) false positive only on AG - actually at AG, can't remember soon.

[Yuki2718]

Maybe https://github.com/AdguardTeam/AdguardFilters/issues/90055 Already fixed by EL and the link no more work but IIRC uBO didn't suffer at the time.

[uBlock-user]

As for the differences in behaviour with $popup with regards to ABP and uBO, the only ideal solution for that would be for both the developers of the extension(ABP and uBO) to come together, write a spec for $popup and implement it, so the behaviour is common and there are no differences( like it was done for $removeparam with AG.)

[dimisa-RUAdList]

Yes, that would be the perfect solution.

[LucianAndries]

Hello.

I have a similar issue on a website. It always opens a new window with a specific address. It does it no matter where I click, it does it even by reloading a page................ The popup is not related to anything, because all the links are different from the popup. I have no idea what triggers it, it's not a redirect either.

This popup: http://aniwatcher.com/search?q=ready

And knowing the link, I created custom filters for it. Filters like: ||aniwatcher.com/search?q=ready$popup,important ||aniwatcher.com/search?q=ready$popunder,important ||aniwatcher.com/search?q=ready

And the thing still opens this popup. And don't get me started with this "about:blank"............... And if nobody figured it out, this is the website "aniwatcher.com".

Are there any more special commands to block these stupid popups? :(

I keep uBlock on default settings, using the built-in filters. And there's no filter that interferes with mine. Also, I'm not using any dynamic filtering, I know those break everything. I'm using latest Chrome, and latest Windows 10 Pro.

So does anyone have more ideas or advices in how to force block it? Because if that's it, then it has to be a bug, right? :( Also, I only want to block that link, not all popups on that domain. Because I tend to open new shows in new tabs. Otherwise I could just block everything.

[Yuki2718]

@LucianAndries I don't get any popup. Probably better to report with built-in report tool with all the details.