Opened 2 years ago

Closed 7 weeks 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

  1. Navigate to ​https://kobieta.onet.pl/
  2. Note your blocked count.
  3. Add the following filter to ABP: @@|https://kobieta.onet.pl/|$document
  4. 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)

5645-whitelist-filter-blocking.jpg​ (321.2 KB) - added by Ross 2 years ago.

Download all attachments as: .zip

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)

As mentioned in the email discussion I can not reproduce this as described with Chrome 60.

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?

Last edited 2 years ago by BrentM (previous) (diff)

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 7 weeks 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.

Note: See TracTickets for help on using tickets.