-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: to
network modifier
#4524
base: master
Are you sure you want to change the base?
Conversation
to
network modifier
Despite we marked it's not safe to add one more bit before, but it's still safe to use 31st bit given that we're treating the number as unsigned integer. > const buf = new Uint8Array(4)
undefined
> buf.length
4
> buf[0] = (1 << 31) >>> 24
128
> buf
Uint8Array(4) [ 128, 0, 0, 0 ]
> (buf[0] << 24) >>> 0
2147483648 |
@@ -153,6 +153,7 @@ export const enum NETWORK_FILTER_MASK { | |||
isHostnameAnchor = 1 << 28, | |||
isRedirectRule = 1 << 29, | |||
isRedirect = 1 << 30, | |||
isTo = 1 << 31, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need the flag? looks like it is never read
it should not be needed if we convert $to
to $denyallow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is required to build an original form in toString
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is good enough reason to use the slot in the mask
context('to', () => { | ||
it('fails when both denyallow and to used', () => { | ||
network('||foo.com$denyallow=foo.com,to=bar.com', null); | ||
network('||foo.com$to=foo.com,denyallow=bar.com', null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if both present, can we merge them instead of dropping?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can normalize them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets try to do that please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in 35c36cc
This partially implements https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#to.
In the documentation,
to
is described as:However, we already support entity-based syntax in
Domains
and only thing required is negation according to entity documentation: https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#entityWe still don't support regular expression both in
domain
anddenyallow
options. Same goes forto
:*$to=~/regex.../
.denyallow
with uBo: ✅ negation and listing ❌ entities ❌ regexto
with uBo: ✅ negation and listing ✅ entities ✅ regexdenyallow
,to
with Ghostery: ✅ negation and listing ✅ entities ❌ regexThis PR negates all hostnames in parse-time to flip the behavior of
denyallow
whento
is detected.Also, rejects to parse filter having both
denyallow
andto
since both are not likely to be used together.We can merge multiple domains then make it work but then we'll require extra space that allows us to determine which hostname is for
to
anddenyallow
when runningtoString
.This PR also fixes
denyallow
domain list not being printed in a correct format fromtoString
method. There's a same regression intoString
regrading other network modifiers utilizingDomains
likefrom
and planned to fix in separate PR.