Opened on 09/08/2017 at 12:54:25 PM
Closed on 08/29/2019 at 05:48:47 PM
#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 on 09/08/2017 at 12:55:05 PM by Ross
comment:1 Changed on 09/08/2017 at 06:22:54 PM by sebastian
- Cc sebastian kzar added
- Component changed from Unknown to Platform
- Description modified (diff)
comment:3 Changed on 09/13/2017 at 06:50:49 AM by mapx
- Cc mapx added
comment:4 Changed on 09/14/2017 at 04:41:58 PM 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 on 09/14/2017 at 05:14:11 PM 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 on 09/14/2017 at 05:18:52 PM 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 on 09/19/2017 at 05:59:29 PM by sebastian
For reference, #5674 (duplicate) is about the very same issue on outlook.com.
comment:8 Changed on 09/19/2017 at 06:14:52 PM 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 on 09/19/2017 at 06:18:50 PM 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 on 08/29/2019 at 05:48:47 PM 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.