ABP Detection not working on Safari

[esanchez]

Environment

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

How to reproduce

1. Browse to ​http://gamerant.com/6-best-upcoming-vr-horror-games-666/
2. Open the developer console / network connections tab.

Observed behaviour

• srv.yavli.com/px.gif?ch=1 loads successfully.
• srv.yavli.com/px.gif?ch=2 loads successfully.

Expected behaviour

• srv.yavli.com/px.gif?ch=1 loads successfully.
• srv.yavli.com/px.gif?ch=2 should be blocked.

(Which happens with the Chrome extension.)

Notes

These are the relevant filters in ​exceptionrules.txt

||srv.yavli.com/px.gif?ch=2&rn=$domain=destructoid.com|gamerant.com|aplus.com|newser.com|whatculture.com|inquisitr.com
@@||srv.yavli.com/px.gif?ch=1&rn=$domain=destructoid.com|gamerant.com|aplus.com|newser.com|whatculture.com|inquisitr.com

[esanchez]

Safari ABP preferences Panel

[kzar]

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 srv.yavli.com/px.gif?ch=1 also be blocked?

[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 srv.yavli.com/px.gif?ch=1 also be blocked?

The filters listed are already in the exceptions list.

srv.yavli.com/px.gif?ch=1 should load, srv.yavli.com/px.gif?ch=2 should be blocked

[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)

[kzar]

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.

[kzar]

Can reproduce as described, investigating.

[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="//jscode.yavli.com/unit-38.js" async defer></script>

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

  var px = "//srv.yavli.com/px.gif?ch=*&rn=*";
  var random = Math.random() * 11;
  var img1 = new Image;
  img1.onload = ...;
  img1.onerror = ...;
  img1.src = px.replace(/\*/, 1).replace(/\*/, random);

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

[kzar]

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.

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

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

[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.4.7.1.4) 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): ​http://static.muzzee.net/aa-detect.html

[arthur]

@kvas
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?

[kvas]

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.