Improve engine events to expose internal workflow #3881
+466
−79
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chrmod
requested changes
Apr 4, 2024
There was a problem hiding this comment.
Few things to address:
- To have a better overview we should also emit information of the exceptions (unHide), similarly to how it is being done for the network matches.
- how about we have one new event, lets call it
matchthat would fire for both network and cosmetic filters. It's params should look alike for both types. (don't remove old event, they important for backwards compatibility)
I see it like this:
const context = { tabId: 1, frameId: 2 };
engine.getCosmeticsFilters(oldParams, withMetadata, context);
engine.match(request, withMetadata, context);
engine.on('match', (context, result) => {
console.log(context, result.match, result.exception, result.metadata);
});
Notice withMetadata for getCosmeticsFilters this is another capability to remember about. The result for the cosmetic filters should include the metadata in the same way the network result does.
|
@remusao I'd like to get a feedback about the way passing "context" to matching functions. It might help a lot for extension developers often used to involve @chrmod This is actually an off-topic but if we involve Passing an external context can solve many complex situations but I'd like to go simple as possible. For example, we could decorate the passed |
chrmod
reviewed
Apr 5, 2024
remusao
reviewed
Apr 6, 2024
remusao
reviewed
Apr 6, 2024
remusao
reviewed
Apr 6, 2024
| console.log('extended-rule-matched', rule, context); | ||
| }); | ||
|
|
||
| blocker.on('style-rule-matched', (rule, context) => { |
There was a problem hiding this comment.
I wonder if we could make it clearer in the naming that this is a hostname-based march of a cosmetic rule. Also, that it does not mean it marched in the page, just that it was selected by the engine as a candidate to be injected (I think it’s important to make this clear to avoid confusion)
remusao
requested changes
Apr 22, 2024
chrmod
reviewed
Apr 30, 2024
chrmod
requested changes
Apr 30, 2024
There was a problem hiding this comment.
Not sure if we need that many new events. How about we introduce one filter-matched which would emit:
- a filter, cosmetic or network
- a function name used to acquire the filter, like
match,getHtmlFilters,getCosmeticsFilters - function arguments, which can include additional info like the
context: any. For network filters it is most important to get the request.
Additionally, would like to set a naming convention for the public interfaces for the filters. Sometimes we call those things rules (for instance in context of Cosmetic bucket), but on the interface level I would strony suggest we always call both network and cosmetic "rule" with a name of filters.
This will be a contrast to the DNR, where after conversion the filters become the rules.
|
In the last changes, the events were narrowed down to two: Also, the commit addresses the followings:
|
seia-soto
changed the title
chrmod
requested changes
May 6, 2024
chrmod
requested changes
May 9, 2024
There was a problem hiding this comment.
Looks like while we develop this feature it started to change direction. All good, but it also got a bit complex. Lets try to simplify a bit before moving forward.
To recap the goal: We want to introduce new events that would allow us to implement a logger that is able to list matched filters and exceptions in a context of a given tab.
| @@ -1035,6 +1195,8 @@ export default class FilterEngine extends EventEmitter< | |||
|
|
|||
| // Emit events if we found a match | |||
| if (result.exception !== undefined) { | |||
| this.emit('filter-matched', result.exception, context); | |||
|
|
|||
| this.emit('request-whitelisted', request, result); | |||
| } else if (result.redirect !== undefined) { | |||
There was a problem hiding this comment.
shouldn't we emit redirects as well?
There was a problem hiding this comment.
This is treated as a normal filter (result.filter) before being registered as result.redirect. The event should be triggered right after the filter match.
chrmod
requested changes
May 13, 2024
chrmod
reviewed
May 14, 2024
chrmod
approved these changes
May 24, 2024
remusao
requested changes
May 26, 2024
There was a problem hiding this comment.
Could you please add unit tests for each of the event with cases where they should/shouldn't trigger?
Also, please do run the benchmark to validate that there isn't extra overhead with the additional data-structures we are creating on each call to engine matching functions.
chrmod
requested changes
May 27, 2024
There was a problem hiding this comment.
thanks to @remusao comments I've realised that we should populate the reference in all the helper libraries, that is adblocker-webextension, adblocker-puppeteer, and adblocker-playwrights. If we wont, customers of those libraries wont be able to distinguish the source of events from getCosmeticsFilters so for examples in browsers, those events wont be useful.
chrmod
requested changes
May 27, 2024
seia-soto
force-pushed
the
emit-cosmetic-filter-matches
branch
from
d9c6b86
to
ba99f8a
Compare
Benchmarking resultsseia-soto:emit-cosmetic-filter-matches Detailsmaster Details |
|
Base: Avg serialization time (100 samples): 190.044 μs (+ 59.886 μs) Total requests: 233,347 Number of samples: 94,294 Number of samples: 139,053 Number of samples: 233,347 |
chrmod
approved these changes
Jun 10, 2024
|
Updated benchmarking. Skipping: serialization, list parsing, and initialization time - as these are not affected by this PR For matched filters (94k samples), the maximum matching time increased a lot: from 1,770.5 μs to 4,453.25 μs. This can be seen as a big deal but if we look at the average: from 6.62 μs to 6.906 μs - , it shows that the processing time grows by following the linear graph. For exception + unmatched filters (139k samples), the maximum matching time decreased: from 5,513.208 μs to 3,402.334 μs. This is because this PR dropped maximum 3 comparisons of if statements for exceptions if there's no listeners. For the overall result (94k+139k samples), see the following:
Full logs |
chrmod
requested changes
Jun 10, 2024
|
After the optimisation, the performance overhead is in minimal considering the CPU time difference coming from list parsing time. For the matching process: min -0.041 μs, max -12.501 μs, avg +0.016 μs Full logs |
chrmod
approved these changes
Jun 11, 2024
remusao
requested changes
Jun 17, 2024
|
|
||
| // Additional context given from user | ||
| matchType: FilterType.COSMETIC; | ||
| reference: any; |
There was a problem hiding this comment.
I already commented on the naming of reference in another thread. Would it also make sense to type it with a generic type parameter T instead of any?
There was a problem hiding this comment.
We've discussed that and IMO a generic type would influence all signatures by putting a strong emphasis on itself, even if no listeners are in use.
What I mean, new users of for example getCosmeticsFilters, should not think about such T.
Comment on lines
+922
to
+937
| url, | ||
| domain, | ||
| hostname, | ||
|
|
||
| classes, | ||
| hrefs, | ||
| ids, | ||
|
|
||
| allowGenericHides, | ||
| allowSpecificHides, | ||
|
|
||
| getBaseRules, | ||
| getInjectionRules, | ||
| getExtendedRules, | ||
| getRulesFromDOM, | ||
| getRulesFromHostname, |
There was a problem hiding this comment.
Nit. Would it make sense to reuse part of the object we already create in the arguments for the function call above instead of duplicating?
There was a problem hiding this comment.
like this?
const context: CosmeticFilterMatchingContext = {
...arguments[0],
isFilterExcluded: undefined,
filterType: FilterType.COSMETIC,
};
Co-authored-by: Remi <remusao@users.noreply.github.com>
Co-authored-by: remi <remusao@users.noreply.github.com>
Co-authored-by: Remi <remusao@users.noreply.github.com>
chrmod
reviewed
Jun 17, 2024
chrmod
reviewed
Jun 18, 2024
chrmod
reviewed
Jun 19, 2024
|
|
||
| export type CosmeticFilterMatchingContext = CosmeticFilterMatchingContextBase & | ||
| Partial< | ||
| Omit<Parameters<FilterEngine['getCosmeticsFilters']>[0], 'callerContext'> & |
chrmod
reviewed
Jun 19, 2024
Comment on lines
+788
to
+790
| if (htmlSelectors.length !== 0) { | ||
| this.emit('html-filtered', htmlSelectors, url, context); | ||
| } |
There was a problem hiding this comment.
this should be in the this.hasListeners('html-filtered') check
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #3876