Opened 2 years ago
Closed 3 months ago
#5645 closed defect (rejected)
Requests still blocked with white-listing filter applied
Reported by: | Ross | Assignee: | |
---|---|---|---|
Priority: | Unknown | Milestone: | |
Module: | Platform | Keywords: | closed-in-favor-of-gitlab |
Cc: | sebastian, kzar, mapx, BrentM, greiner | Blocked By: | |
Blocking: | Platform: | Chrome | |
Ready: | no | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description (last modified by kzar)
Environment
ABP 1.13.3.1838
Chrome 60 / Windows Vista
EasyList and EasyPrivacy subscriptions
How to reproduce
- Navigate to https://kobieta.onet.pl/
- Note your blocked count.
- Add the following filter to ABP: @@|https://kobieta.onet.pl/|$document
- Open the ABP DevTools panel in the kobieta tab and refresh the page.
Observed behaviour
Several requests are still blocked by EasyPrivacy.
Expected behaviour
The site to appear white-listed with no requests blocked.
Attachments (1)
Change History (11)
Changed 2 years ago by Ross
comment:1 Changed 2 years ago by sebastian
- Cc sebastian kzar added
- Component changed from Unknown to Platform
- Description modified (diff)
comment:2 Changed 2 years ago by kzar
- Description modified (diff)
comment:3 Changed 2 years ago by mapx
- Cc mapx added
comment:4 Changed 2 years ago by BrentM
All
I finally had some time to research this issue a bit more. It appears that the the above web site is using Service Workers to load some of the JavaScript files for the page. The details (tab id, frame id, etc) about a request loaded via Service Workers always seems to be -1 (at least with my current version of Chrome - 61.0.3163.79).
This doesn't explain why Dave and Sebastian don't see the issue, but I think that's the issue - the requests can't be associated to a specific tab / frame, so we don't know that the page is white-listed. Correct?
Also, could I get added to the 'CC' list for this issue?
comment:5 Changed 2 years ago by sebastian
- Cc BrentM added
Yes, this is a known limitation (Chrome bug 705931). As these requests aren't associated with any document's tabId, document-based whitelisting won't work obviously.
The only way to avoid that would be by never blocking any request with tabId == -1. We did exactly that before Adblock Plus 1.12.3, but changed this (#5042) as it has been misused for circumvention.
comment:6 Changed 2 years ago by BrentM
Thanks for the link of the Chrome bug. I couldn't find it earlier.
Also, I just checked the above site again, and it doesn't seem to using Service Workers now. They seem to be updating it often.
Also, I checked Firefox web extensions, and they have a similar behavior as Chrome.
comment:7 Changed 2 years ago by sebastian
For reference, #5674 (duplicate) is about the very same issue on outlook.com.
comment:8 Changed 2 years ago by greiner
- Cc greiner added
Given that such scenarios appear to have become more common, #5093 would be a relatively easy way to improve the current situation by helping filter authors and us identify such issues quicker.
comment:9 Changed 2 years ago by sebastian
Well, UI is your module, feel free to prioritize #5093 accordingly, if you think it is important. ;)
But FWIW, you can already identify such requests in the "Adblock Plus" developer tools panel by their empty "Document domain".
comment:10 Changed 3 months ago by sebastian
- Keywords closed-in-favor-of-gitlab added
- Resolution set to rejected
- Status changed from new to closed
Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the new issue tracker.
As mentioned in the email discussion I can not reproduce this as described with Chrome 60.