Opened on 08/30/2016 at 05:02:56 PM

Closed on 09/15/2016 at 12:19:48 PM

Last modified on 01/24/2018 at 09:54:14 AM

#4384 closed defect (rejected)

ABP Detection not working on Safari

Reported by: esanchez Assignee:
Priority: P2 Milestone:
Module: Platform Keywords:
Cc: kzar, sebastian, arthur, kvas Blocked By:
Blocking: Platform: Safari
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)


OS X 10.11, Safari 9, Adblock Plus 1.12.2(?)
EasyList and Acceptable ads subscriptions enabled.

How to reproduce

  1. Browse to
  2. Open the developer console / network connections tab.

Observed behaviour

  • loads successfully.
  • loads successfully.

Expected behaviour

  • loads successfully.
  • should be blocked.

(Which happens with the Chrome extension.)


These are the relevant filters in exceptionrules.txt


Attachments (2)

80552AFD-477A-4387-8570-9CC1C07672CE.png (177.6 KB) - added by esanchez on 08/30/2016 at 05:03:45 PM.
Safari ABP preferences Panel
Screen Shot 2018-01-23 at 17.29.05.png (169.5 KB) - added by arthur on 01/23/2018 at 04:39:30 PM.

Download all attachments as: .zip

Change History (18)

Changed on 08/30/2016 at 05:03:45 PM by esanchez

Safari ABP preferences Panel

comment:1 follow-up: Changed on 08/30/2016 at 05:31:57 PM by kzar

  • Cc kzar sebastian added; removed
  • Description modified (diff)

Thanks for filing the issue.

I have corrected the usernames on CC, if you install the Eyeo Helpers extension you'll be given better suggestions and it'll be easier to get those right. Trac is quite bad in that regard.

I have also tidied up the description but some clarification is still required:

  • What version of Safari and Adblock Plus are you using?
  • Are you using any filter subscriptions? If so what are they? (That includes the Acceptable Ads exception subscription.)
  • Are those filters you've listed in the subscriptions you have enabled?
  • Should also be blocked?

comment:2 Changed on 08/31/2016 at 08:08:15 AM by arthur

  • Cc arthur added

comment:3 Changed on 09/05/2016 at 12:42:59 PM by esanchez

  • Description modified (diff)
  • Summary changed from Filter rule being ignored in Safari on to ABP Detection not working on Safari -- All sites possible affected

comment:4 in reply to: ↑ 1 Changed on 09/05/2016 at 03:16:58 PM by esanchez

Thanks for fixing and giving suggestions.

To answer the questions:

What version of Safari and Adblock Plus are you using?

I tested using on Browserstak using osX Mavericks with Safari 7.1 and saw the same issue.

We also tested on webmate, however we did not write down the version, we believe it was Safari 9.1, but webmate is down now so we will confirm later. What I do know is we downloaded ABP for this specific test so ABP version should be latest.

I also tested on Mario's MacBook, but I did not find him so I will confirm later.

Are you using any filter subscriptions? If so what are they? (That includes the Acceptable Ads exception subscription.)

Just easy list and Exception list

Are those filters you've listed in the subscriptions you have enabled?
Should also be blocked?

The filters listed are already in the exceptions list. should load, should be blocked

comment:5 Changed on 09/05/2016 at 03:29:57 PM by esanchez

Got versions used on WebMate: OS X 10.11 Safari 9, Latest ABP (Still can not run the VM due to some errors on webmate's side)

comment:6 Changed on 09/15/2016 at 08:09:07 AM by kzar

  • Description modified (diff)
  • Summary changed from ABP Detection not working on Safari -- All sites possible affected to ABP Detection not working on Safari

When you say latest ABP do you mean the latest development build or the latest release? (I'll assume you meant the latest release 1.12.2 for now, but my point is that you need to specify the actual version numbers/names when filing issues. We need them in order to reproduce problems, which is the first step in fixing them.)

Also please omit speculation like "X might be the case" in issue descriptions, stick to concrete facts. The primary purpose of the issue description for bugs like this is to help the developer reproduce the problem. (You can add a notes or references section to the bottom of the description if you like with extra notes or references if you like.)

Anyway this issue is looking good now, thanks for your patience with it. I'll now try to reproduce the problem.

comment:7 Changed on 09/15/2016 at 08:22:18 AM by kzar

  • Description modified (diff)
  • Owner set to kzar
  • Priority changed from Unknown to P2
  • Ready set

Can reproduce as described, investigating.

comment:8 Changed on 09/15/2016 at 11:00:09 AM by kzar

So it appears our beforeload event listener doesn't see those requests at all, which explains why they're not blocked!

That page has the following script tag:

<script type="text/rocketscript" charset="utf-8" id="yvli_unit38" data-rocketsrc="//" async defer></script>

and that script does something like this to perform the requests:

  var px = "//*&rn=*";
  var random = Math.random() * 11;
  var img1 = new Image;
  img1.onload = ...;
  img1.onerror = ...;
  img1.src = px.replace(/\*/, 1).replace(/\*/, random);
Last edited on 09/15/2016 at 11:49:47 AM by kzar

comment:9 Changed on 09/15/2016 at 11:48:42 AM by kzar

OK it seems if you first append the image element to the document body, then assign the src attribute Adblock Plus catches the beforeload event. Something like this:

var image = document.body.appendChild(new Image());
image.src = ...;

I've made a small test page to demonstrate. Add the filter and notice that in Chrome three requests are blocked, but in Safari only two are.

So seems like we'll need to adjust the detection script, rather than changing Adblock Plus for Safari. But before we do that I noticed another problem, requests are actually still made for the two blocked images despite being listed as blocked. (Even grumpy.jpg?static!)

Continuing to investigate...

comment:10 Changed on 09/15/2016 at 12:19:26 PM by kzar

  • Owner kzar deleted

Well even when I have our beforeload listener immediately cancel all requests the network request is still actually made. So I don't think this detection approach can ever work properly for Safari.

Perhaps have the detection script create an element that tests element hiding instead? If the element is hidden you could then create an image element to perform the px.gif request. I think that should work for Safari.

Since this now requires changes to the detection script rather than Adblock Plus for Safari I will close this issue.

comment:11 Changed on 09/15/2016 at 12:19:48 PM by kzar

  • Resolution set to rejected
  • Status changed from new to closed

comment:12 Changed on 09/15/2016 at 12:41:36 PM by kzar

I was asked about how to proceed with the detection script in IRC, responding here to keep everything together.

If you only care about the onerror and onload events being fired then simply modify the detection script to first attach the image element to the document before assigning the src attribute. Something like the example I gave earlier:

var image = document.body.appendChild(new Image());
image.onload = ...;
image.onerror = ...;
image.src = "example.png";

That should then work as you expect.

If however you do care that the network request to "example.png" will always be made, for example perhaps you're monitoring requests on the server side, then I think a whole new approach will be required.

In that case I think you will need to add element hiding rules to exceptionrules.txt instead of blocking rules. You could then have the detection script inject an element, check if it's hidden, then create an image element in order to perform a request to share the result.

Last edited on 09/15/2016 at 12:43:45 PM by kzar

comment:13 Changed on 10/07/2016 at 02:39:49 PM by esanchez

To add here:

  • appending the image to the body does solve the issue but that has to be changed by the partner.
  • Enabling the experimental feature fixes the issue.

comment:14 Changed on 01/04/2018 at 06:05:20 PM by kvas

I spent some time looking into a similar problem today for the AAX. Everything worked in the end, but I'm documenting it here for future reference.

I used Safari 11.0.2 (11604. with ABP 1.12.4.

Initially I worked with a local HTML file and the detection didn't work (although does work in Chrome and Firefox). Then after seeing this ticket and trying kzar's example, I realized that there's an apparent difference in behavior for local pages vs pages loaded from a server. This breaks detection for local pages (in Safari), but it still works fine for pages that are loaded from a server. Not sure why the difference, but in practice all real pages would be loaded from a server, so it seems like we should be fine.

In the process I've set up this testing page (it uses one of the AAX rules that have been recently been added to AA whitelist and also AAX detection pixel):

comment:15 Changed on 01/23/2018 at 04:39:19 PM by arthur

Is that how it suppose to look like? ABP is blocking 2 resources but according to the dev tools the 2 pixels aren't blocked?

Changed on 01/23/2018 at 04:39:30 PM by arthur

comment:16 Changed on 01/24/2018 at 09:51:40 AM by kvas

  • Cc kvas added

Yeah, for me the dev panel looks the same (pixel requests are shown as successful). This doesn't affect the AA detection (the script sees onerror handler called for the blocked image), but it might mean that the request is made anyway, which could be a problem for the actual blocking.

Last edited on 01/24/2018 at 09:54:14 AM by kvas

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none).
Note: See TracTickets for help on using tickets.