Notify of blockable items independently of filter matches
Background
When listening to requests and filter matches using EWE.reporting.onBlockableItem
, it returns both matched and unmatched requests. It does that, however, by returning either a matched or an unmatched request for each matching method, making it impractical to make sense of them.
For example, here's an excerpt of what we're getting when running below code and loading greinr.com:
EWE.reporting.onBlockableItem.addListener(
({details, filter, info}) => console.log(details.url, filter && filter.text, info.matchingMethod),
{
filterType: "all",
includeElementHiding: true,
includeUnmatched: true
}
)
EWE.filters.add("greinr.com$image,domain=greinr.com")
EWE.filters.add("@@greinr.com$genericblock")
EWE.filters.add("@@greinr.com$elemhide")
Request | Filter? | Matching method |
---|---|---|
/ | null | csp |
/ | @@greinr.com$elemhide | allowing |
/ | @@greinr.com$genericblock | allowing |
/favicon.ico | greinr.com$image,domain=greinr.com | request |
/shared/css/general.css | null | header |
/shared/css/general.css | null | request |
/shared/fonts/JosefinSansStd-Light.woff | null | header |
/shared/fonts/JosefinSansStd-Light.woff | null | request |
/shared/img/g45.png | greinr.com$image,domain=greinr.com | request |
/shared/img/me.jpg | greinr.com$image,domain=greinr.com | request |
/shared/img/me50.jpg | greinr.com$image,domain=greinr.com | request |
/shared/js/G.js | null | header |
/shared/js/G.js | null | request |
/www/home/css/index.css | null | header |
/www/home/css/index.css | null | request |
/www/home/img/background-sprite.png | greinr.com$image,domain=greinr.com | request |
/www/home/img/social.png | greinr.com$image,domain=greinr.com | request |
/www/home/js/index.js | null | header |
/www/home/js/index.js | null | request |
From that you can see the following:
- Some requests are duplicated due to the "header" matching method.
- Some requests are duplicated due to matching multiple filters.
Therefore, in order to compile a list of all requests without duplicates, we have to:
- Ignore events whose matching method is not "allowing" or "request", because those are redundant.
- Ignore events for the same request, but with different filters.
While the former is technically possible - albeit a workaround - the latter doesn't seem possible without keeping track of request IDs.
Use case
- Deduplicate items to avoid overcounting requests in issue reports (e.g. workaround attempt: code, code).
- Deduplicate items to avoid same request being shown multiple times in developer tools panel (e.g. workaround attempt: code, code).
- Avoid situations where unmatched "main_frame"-type requests are shown in the developer tools panel or included in issue reports.
Suggested change
- Notify of blockable items and of filter matches independently of each other.
- Notify of each blockable item only once.
That way, we should only receive each request once (without having to try to awkwardly compare and combine matched and unmatched requests), but should still able to associate zero, one or more filter matches to each of those requests after the fact.
Further information
Note that EWE.reporting.contentTypesMap.get("main_frame")
returns undefined
, so we currently have to hardcode its content type mapping (see code and code).