OK, I've been racking my brains at this and I don't think we can solve this before the merge. I can't find a way to achieve all the logic with the available information, even with some compromises.
Here is a summary of the ideal truth state of ThirdPartyCookies.isDetected(contentBlockingEvent) where contentBlockingEvent is the bitfield with the blocked/loaded states:
- isDetected controls whether the category item is clickable, to go into the subview.
- The category item should not be clickable, if the subview is going to be empty when it's opened.
- Therefore, isDetected means, we have cookies to show in the subview.
The subview shows either the cookies being blocked, or the cross-site tracking cookies we've allowed.
- If we are set to block some type of cookie, isDetected should be true if we have blocked cookies, or we have loaded a cookie that we otherwise would have blocked due to an exception (impossible to know because the content blocking event doesn't seem to give us an origin! Please let me know if I'm wrong about this)
- If we are set to allow cookies, we want to show the cross-site tracking cookies we WOULD HAVE blocked, in the subview. Therefore, isDetected should be true if we have loaded tracker cookies. This is impossible to know based on the web progress state alone. A compromise is to use ((we have loaded cookies) && (we have loaded trackers)) and while that's better than nothing, it's still not too great IMO.
All the information we need is in the content blocking log, which I don't want to fetch and parse every time we get a content blocking event. Is there a reason we don't pass all the information of a log entry to
onContentBlockingEvent? How difficult would it be to extend the content blocking event notification system to share the origin of the content being blocked? That would help immensely. I couldn't find any ways to get anything useful from the nsIWebProgress instance that's available.
Johann, one hack I can think of to make this work to some extent is to be less lazy about updating the subview, i.e. do it either when the panel is opened and/or when the page load is complete, and from there determine the
notFound state of the category item. What do you think of this?