uBlockOrigin / uBOL-home

uBO Lite home (MV3)
GNU General Public License v3.0
828 stars 35 forks source link

Add ability to translate `header=` into DNR `responseHeaders` condition #157

Open Nexus-Gits opened 1 month ago

Nexus-Gits commented 1 month ago

Prerequisites

URL(s) where the issue occurs.

https://yomovies.farm/

Description

Ads do not block by ublock origin lite on this site. when play video it pop up ads

Other extensions used

nothing.

Screenshot(s)

Screenshot(s)

Configuration

Details ```yaml ```
gorhill commented 1 month ago

Possibly because the following filter can't be translated into a DNR rule for multiple reasons:

/^https?:\/\/(?:[a-z]{2}\.)?[0-9a-z]{5,16}\.[a-z]{3,7}\/[a-z](?=[a-z]{0,25}[0-9A-Z])[0-9a-zA-Z]{3,26}\/\d{4,5}(?:\?[_v]=\d+)?$/$script,3p,redirect-rule=noop.js,match-case
stephenhawk8054 commented 1 month ago

@gorhill Sorry, can MV3 use header now? I see the issue linked here is closed: https://github.com/w3c/webextensions/issues/460

I think this issue can be solved by

*$script,3p,domain=minoplres.xyz,header=Access-Control-Allow-Headers:/megageocheckolololo/

if header is supported

Celsius273 commented 1 month ago

response header matching was added in Chrome M128, so whenever that version lands?

gorhill commented 1 month ago

From RuleCondition documentation, responseHeaders support is pending. Also, as per HeaderInfo documentation, if the value to match is a regex, it will have to be translatable into simple pattern matching syntax, where only * and ? are supported.

Conversion of header= filters into DNR rules will have to wait for support to be official in stable release, and also to be sure that presence of responseHeaders rules does not break the extension on older versions of the browser not supporting the capability.

danielhjacobs commented 1 month ago

and also to be sure that presence of responseHeaders rules does not break the extension on older versions of the browser not supporting the capability

From my experience with https://github.com/ruffle-rs/ruffle/pull/16694, this is doable with just a try/catch for adding the rule conditions on other browsers and older versions of Chrome that hadn't even begun implementing this rule condition, but on versions of Chrome that began implementing this feature behind a flag, adding the rule conditions does not throw but they take into account only their other conditions if the flag is not enabled, which may be undesirable. I had to use this code, suggested by Rob W from the Firefox team, to create a function to detect whether these conditions were really supported before registering them to work around that: https://github.com/w3c/webextensions/issues/638#issuecomment-2181124486. This is the Chrome bug indicating features developed behind a flag are not fully hidden behind the flag: https://issues.chromium.org/issues/347186592#comment9

It may be different for rules registered in the manifest.

gorhill commented 4 days ago

It would help if uBO's header= syntax matched the DNR's HeaderInfo's syntax:

If specified, this condition matches if the header's value matches at least one pattern in this list. This supports case-insensitive header value matching plus the following constructs: * : Matches any number of characters. ? : Matches zero or one character(s). * and ? can be escaped with a backslash, e.g. \* and \?

I think uBO could supports the DNR's pattern matching syntax. uBO would still support the regex syntax, which would need to be dropped from the conversion, but plain or pattern-matching syntax would be translated to DNR rule with no special processing.