Uassets: gmx.net filter

[Procyon-b]

This is related to #6541 but I feel that since that issue is closed, my comment will be unnoticed.
Here is the comment I made there.

While using gmx.net webmail, I see +js(json-prune, enabled, force_disabled) appearing in the logger.

The current filter is:

! https://github.com/uBlockOrigin/uAssets/issues/6541
focus.de,gamesaktuell.de,gmx.*,kino.de,spieletipps.de,videogameszone.de,web.de##+js(json-prune, enabled, force_disabled)

This is unnecessary on that site.

Could you fix this by refining the domain and use www.gmx.* in the filter instead of gmx.*.
The filter target is too wide. It's like shooting at all .com when you are aiming at github.com.
And narrowing it to www.gmx.*/magazine could even be better (but that, I'm not sure).

[krystian3w]

And narrowing it to www.gmx.*/magazine could even be better (but that, I'm not sure).

If mail service no works on subdomain** we can't create exception / exclusion.

"Folders"/"catalogs" 'magazine' can by used in network filters not in cosmetic filters.

---

** - e.g.: mail.gmx.net, box.gmx.net, post.gmx.net.

[krystian3w]

@lain566 you have mail on GMX and web client works only on mm.gmx.net subdomain?

[Procyon-b]

It's not an issue of not working. It's the fact that the filter is applied to pages and subdomain where it's not needed.
I haven't followed the original problem, but from what I can read, the example page is on https://www.gmx.net/magazine/. I don't see the point of targeting *.gmx.* instead of www.gmx.*. That's all I say. ;)
Gmx has other subdomains ; at least 6 for the webmail portal.

[lain566]

I don't have a GMX mail account.
@Procyon-b You say it is unnecessary, but what is the breakage or does it just bother you that the filter is applied to all subdomains?

[Procyon-b]

Let me be clear. :)

The original problem, as described in #6541 , is that videos were blocked on www.gmx.net/magazine, which is a news portal.
The filter created for this issue applies to all gmx.* subdomains. It doesn't cause any problem on the webmail portal, but it is useless there, since, afaik, there are not video played on that site (not a www.gmx.* domain).

The reasoning behind my remarks is that, if the same logic is applied to most situations (applying fixes to a wider domain range than the original problem) we might end up sometimes with filters causing problems elsewhere.

Beyond that it doesn't bother me.

Edit:
The reason I noticed the filter is that I was debugging a userscript and wanted to know the exact url of an iframe, and when it was loaded.

[lain566]

Ok, I did not add the filter gmx.* I don't know the site either, I'm not sure if the site could use any subdomain to show the videos, so I would not like to make a decision without first consulating it with the person who added the filter, especially if the filter is not causing any breakage.
@okiehsch Do you think we should modify gmx.* filter to www.gmx.*?

[mapx-]

If we know the subdomains without videos we could add filters like this one:
search.gmx.com#@#+js(json-prune, config, server)

[krystian3w]

or ~search.gmx.com - uBO translate this into "domain#@#" (ABP / AdGuard nope). Also for scriplets!

See: https://github.com/uBlockOrigin/uBlock-issues/issues/388

[okiehsch]

The reasoning behind my remarks is that, if the same logic is applied to most situations (applying fixes to a wider domain range than the original problem) we might end up sometimes with filters causing problems elsewhere.

I don't think I see the same potential issues, we always use script:injections for the whole site and never check if some subdomains don't really need the filter.

Saying all that you have pointed out that we can change it to www.gmx.*##+js(json-prune, config, server) and I am not against modifying the filter.

What I have observed is that if I add
www.gmx.*##+js(json-prune, config, server)
to my filter list, disable uBO-filters and go to gmx.com.
I see this in the logger.

I can reproduce with Chromium and Firefox
@gorhill

[Procyon-b]

@okiehsch
I have already seen this behavior ("could not be found") while playing with my user filters. I have not (edit) been able to reproduce, but IIRC closing and reopening the logger fixes the issue (when reloading the page).
I think it happens when a list filter is replaced by a similar (but not identical) user filter.

[okiehsch]

I think it happens when a list filter is replaced by a similar (but not identical) user filter.

Not on my end.
I have committed the modified filter, so now to reproduce I just have to update the uBO-filters list and go to gmx.com.

[Procyon-b]

I have found a way to reproduce it.
Load any page with the logger opened. Choose a line that is filtered. Clic to see which filter has been applied. Go to uBo dashboard, disable that list, "update now". Go back to the logger, and open the same filter dialog. Now it displays "Static filter ... could not be found in any of the currently enabled filter lists"

If you have the exact same filter in another list (or in the user filters) the dialog displays that list's name instead.

[okiehsch]

Well, right now I don't have any gmx-related filter in my filter list.
The only script:inject filter for that site is
www.gmx.*##+js(json-prune, config, server)
in uBO-filters. If I go to gmx.com

[lain566]

I can reproduce the same as okiehsch
If i go to gmx.com, gmx.net or gmx.at

[Procyon-b]

Same here.
All my lists are enabled and I see the "could not be found" message.

[gwarser]

I have found a way to reproduce it.
Load any page with the logger opened. Choose a line that is filtered. Clic to see which filter has been applied. Go to uBo dashboard, disable that list, "update now". Go back to the logger, and open the same filter dialog. Now it displays "Static filter ... could not be found in any of the currently enabled filter lists"

This is how it should work.

[Procyon-b]

@gwarser Correct. :) In that situation the text is self-explanatory.

But @okiehsch example doesn't fall into that category.

[krystian3w]

glitch with logger exisist also in 1.23 Commit/a5601b8

[gwarser]

This started with https://github.com/gorhill/uBlock/commit/a73dd0a9f26df59cfb4b68e98d1184ac042c90ea and obviously before this commit scriptlet is not even logged.

[gwarser]

^gmx\.\*$ does not match www.gmx.com in reverselookup-worker.js

[okiehsch]

Can be closed, the issue of the OP has been fixed and the logger issue has been opened in https://github.com/uBlockOrigin/uBlock-issues