Opened 3 years ago

Closed 3 years ago

Last modified 22 months ago

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

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

Attachments (2)

80552AFD-477A-4387-8570-9CC1C07672CE.png (177.6 KB) - added by esanchez 3 years ago.
Safari ABP preferences Panel
Screen Shot 2018-01-23 at 17.29.05.png (169.5 KB) - added by arthur 22 months ago.

Download all attachments as: .zip

Change History (18)

Changed 3 years ago by esanchez

Safari ABP preferences Panel

comment:1 follow-up: Changed 3 years ago by kzar

  • Cc kzar sebastian added; d.barker@… sebastian@… 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 srv.yavli.com/px.gif?ch=1 also be blocked?

comment:2 Changed 3 years ago by arthur

  • Cc arthur added

comment:3 Changed 3 years ago by esanchez

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

comment:4 in reply to: ↑ 1 Changed 3 years ago 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 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

comment:5 Changed 3 years ago 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 3 years ago 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 3 years ago 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 3 years ago 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="//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);
Last edited 3 years ago by kzar (previous) (diff)

comment:9 Changed 3 years ago 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 3 years ago 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 3 years ago by kzar

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

comment:12 Changed 3 years ago 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 3 years ago by kzar (previous) (diff)

comment:13 Changed 3 years ago 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 23 months ago 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.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

comment:15 Changed 22 months ago by 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?

Changed 22 months ago by arthur

comment:16 Changed 22 months ago 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 on_error 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.

Version 0, edited 22 months ago by kvas (next)
Note: See TracTickets for help on using tickets.