The issue with `nsIWebProgressListener.STATE_BLOCKED_TRACKING_CONTENT` is that it does not allow us to differentiate between ad, analytic, social and content trackers. We will either have to split up `STATE_BLOCKED_TRACKING_CONTENT` or continue mapping the GV categories based on `nsIClassifiedChannel.matchedList`. Ehsan, are there any plans to provide more detailed (list-based) flags in `nsIWebProgressListener.onContentBlockingEvent`? Otherwise, GV will need to continue doing the mapping itself based the matched lists, which will probably not work at all for bug 1567611.
Bug 1567268 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The issue with `nsIWebProgressListener.STATE_BLOCKED_TRACKING_CONTENT` is that it does not allow us to differentiate between ad, analytic, social and content trackers. We will either have to split up `STATE_BLOCKED_TRACKING_CONTENT` or continue mapping the GV categories based on `nsIClassifiedChannel.matchedList`. Ehsan, are there any plans to provide more detailed (list-based) flags in `nsIWebProgressListener.onContentBlockingEvent`? Otherwise, GV will need to continue doing the mapping itself based the matched lists, which will probably not work at all for bug 1567611. Alternatively, we could stop reporting at such detail, but that would the break the symmetry between the settings and the reporting, i.e., you can configure GV to block specific categories of trackers (ad, analytic, social, content) but the block reports would not give you this specific category information.
The issue with `nsIWebProgressListener.STATE_BLOCKED_TRACKING_CONTENT` is that it does not allow us to differentiate between ad, analytic, social and content trackers. We will either have to split up `STATE_BLOCKED_TRACKING_CONTENT` or continue mapping the GV categories based on `nsIClassifiedChannel.matchedList`. Ehsan, are there any plans to provide more detailed (list-based) flags in `nsIWebProgressListener.onContentBlockingEvent`? Otherwise, GV will need to continue doing the mapping itself based the matched lists, which will not work at all for bug 1567611. Alternatively, we could stop reporting at such detail, but that would the break the symmetry between the settings and the reporting, i.e., you can configure GV to block specific categories of trackers (ad, analytic, social, content) but the block reports would not give you this specific category information.