Filter issues MUST NOT be reported here. Read first: https://github.com/gorhill/uBlock/blob/master/CONTRIBUTING.md
The documentation for dynamic rules of type 1p-script, 3p, 3p-script, and 3p-frame states that they apply to:
"... pulled from the same domain name of the current web page"
However, the popup creates rules scoped to the full hostname of the site, not the most parent domain. This is inconvenient on sites that use several hostnames because you have to create the same rule for each hostname. You can add the rule for the parent domain manually, but ideally the popup ui should create the rule as described.
The behavior I was expecting, and believe to be most intuitive, is to have the relevant type-based rules use the domain, and the individual hostname rules use the hostname. That way, you can choose 1p-script to apply to the "whole" site, or you could select the hostname rule to only apply to the current page hostname. This will also improve sites that load resources/scripts from a 1st-party sub-domain when defining 1p-script rules.
www.fidelity.com
oltx.fidelity.com
scs.fidelity.com
etc.
Rules:
Results:
Desired
On a site that uses several hosts, such as fidelity.com, use the popup to create a local dynamic filter rule for 1p-script/3p*. Using the site normally will occasionally navigate to one of the other subdomains, and the previously created rules will no longer apply. This also applies to sites that load there resources from a 1st-party sub-domain, of which I can't remember any examples.
Default settings except for enable "I am an advanced user" for access to dynamic filtering
Default filter lists
None
Declined.
You are seriously changing the current behavior of uBO for millions of users. Furtehrmore, It's not _always_ desirable to always use the base domain.
If changing the default behavior isn't desirable, would you be open to enabling it via an advanced option or using a modifier key, or a combination of both? I would be ok with having a global option to enable this behavior explicitly, or to have it triggered for clicks while holding the alt or shift key.
It's not always desirable to always use the base domain
In those cases, you can achieve the same as the current behavior by not using a type-based rule, and creating the rule on the hostname directly, since that is essentially equivalent as things are now.
Also, just in case there was some misunderstanding, I'm not suggesting change anything about how filtering actually happens, only the behavior of the dynamic rules portion of the popup ui.
I re-open to give some thought to this, I can't remember where but this was brought in the past that it should be possible to set the local scope to base domain. At the moment I would be willing to add an advanced setting to always force the local rule to base domain, but that would apply to all rules, not just some of them.
Thanks, that sounds reasonable. I personally prefer the more granular rules for everything but the *-party types, but I can see how having differing behavior could be confusing. I'll update my PR to add an advanced option that applies to all local rules.
Just to confirm I understand, when you say "all rules," you mean both the type-based, and the hostname-based rules correct?
@gorhill
Have you had a chance to give this any more consideration? I still find myself wanting this on a daily basis, so it'd be great I could get my PR merged soon
Most helpful comment
I re-open to give some thought to this, I can't remember where but this was brought in the past that it should be possible to set the local scope to base domain. At the moment I would be willing to add an advanced setting to always force the local rule to base domain, but that would apply to all rules, not just some of them.