Opened 20 months ago

Last modified 19 months ago

#5645 new defect

Requests still blocked with white-listing filter applied

Reported by: Ross Assignee:
Priority: Unknown Milestone:
Module: Platform Keywords:
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 20 months ago.

Download all attachments as: .zip

Change History (10)

Changed 20 months ago by Ross

comment:1 Changed 20 months ago by sebastian

  • Cc sebastian kzar added
  • Component changed from Unknown to Platform
  • Description modified (diff)

comment:2 Changed 20 months 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 20 months ago by mapx

  • Cc mapx added

comment:4 Changed 20 months 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 20 months ago by BrentM (previous) (diff)

comment:5 Changed 20 months 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 20 months 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 19 months ago by sebastian

For reference, #5674 (duplicate) is about the very same issue on outlook.com.

comment:8 Changed 19 months 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 19 months 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".

Note: See TracTickets for help on using tickets.