Loading…
[EasyPrivacy] broken links in Chrome on www.sltrib.com #686
5 participants
Same problem happens with the same version of Chrome (40.0.2214.94) running on both OS X 10.9.5 and 10.10.2.
Problem also occurs with ABP + EasyPrivacy. Please report to EasyPrivacy maintainers: https://forums.lanik.us/viewforum.php?f=64
Thanks. Interesting that it doesn't happen with Safari + uBlock + EasyPrivacy. I wonder what's different.
Safari doesn't allow intercepting XMLHttpRequest if I am not mistaken.
Reported to EasyPrivacy maintainers:
https://forums.lanik.us/viewtopic.php?f=64&t=20846
@chrisaljoudi
Interesting.. I wonder what could be different between your system and mine. I can still reproduce it today using Chrome 40 + uBlock on both OS X 10.9.5 and 10.10.2. I disabled all my other extensions to make sure there is no interference, and it still happens. Perhaps we have slightly different versions of the EasyPrivacy filter list, or different enabled filters? I'll try disabling filters to see if I can narrow it down to a minimal set.
@gorhill
I dug into it a bit and found that Peter Lowe's Ad server list also causes the problem to occur. I emailed a bug report to Lowe. Still don't know why @chrisaljoudi can't reproduce. It is very reproducible for me.
| Test | Result |
|---|---|
| All my filters | BROKEN |
| No filters | works |
| Only uBlock filters | works |
| Only uBlock filters -- Privacy | works |
| Only Anti-Adblock Killer - Reek | works |
| Only EasyList | works |
| Only Peter Lowe's Ad server list | BROKEN |
| Only EasyPrivacy | BROKEN |
| Only Malware Domain list | works |
| Only Malware domains | works |
| Only Malware domains (long-lived) | works |
| Only Anti-ThirdpartySocial | works |
The website works fine despite installing Peter Lowe's Ad server list into my /etc/hosts file and disabling all browser extensions including uBlock. There must be something more to the problem than simply disabling access to that set of hosts.
@fjarlq very interesting (thanks for sharing the data and taking the time to investigate).
I think what's going on, by the way, is in a statement that looks like this on the page:
var x = new Image();
x.src = "http://somehost.com/somethingThatShouldBeBlocked";Which is basically a slightly-sneaky way to issue a request from JavaScript. They never do anything with the image — the src they define is just a tracking request.
With Safari, that request is currently not intercept-able. It goes through, and µBlock never sees it in Safari. No problems.
With Chrome, it is intercept-able. When µBlock stops the requests (as it should), an exceptions seems to get thrown in the context of the creation of that image (or maybe setting the src, I'm not sure). The exception precludes the execution of subsequent statements in that scope.
When using hosts, the JavaScript command succeeds (and the request is made, it just doesn't make it very far). No exception => no problem.
I guess the question now becomes: is there a way to have µBlock in Chrome be able to prevent a request during onBeforeRequest and not cause an exception in situations like this one?
^ the above might be completely, utterly wrong. I'm not 100% confident about this diagnosis.
Confirmed that there's a bunch of exceptions that show up in the JavaScript console (Chrome):
It's probably still a very good idea to have reported this to list maintainers, but it seems like the issue might be more concerned with blocker implementation; I'm still not definitely sure, though.
Interesting... thanks, @chrisaljoudi
Any idea why this breaks clicking on links? I can still right-click and open the links. And hovering over a link causes the URL to be shown in the lower left corner as usual, so Chrome still thinks it's a link. Why do the links become unclickable?
@fjarlq it's probably a click event listener not getting attached appropriately. I'll look to see the specifics if you'd like.
@chrisaljoudi Oh, no need, I was just curious. I didn't know that a broken click event listener could have that effect (but then Javascript and browsers are not my field).
A lot of tracker JS code capture mouse events and cancel the event if their tracker is not working fine, like when a net request is blocked. It's rather common.
@chrisaljoudi These are not exceptions, they are just errors reported by the browser, it doesn't cause exceptions in the JS code. If you say there is an exception, I will look to be sure it does not occur in the content scripts, and if not, well we will have to whitelist whatever filter in Peter Lowe's which block the needed request. Meanwhile EasyPrivacy will have to do the same.
@fjarlq @gorhill yep. You're correct, @gorhill. Sorry I was mistaken.
They're not exceptions. Here's the specific piece of code from the tracker that cancels the event — it's just attached as a click handler:
(function(e
/**/) {
if (e && e.s_fe)
return;
var s = s_c_il[0], f, tcf, t, n;
if (s.d && s.d.all && s.d.all.cppXYctnr)
return;
if (!s.bbc)
s.useForcedLinkTracking = 0;
else if (!s.useForcedLinkTracking) {
s.b.removeEventListener("click", s.bc, true);
s.bbc = s.useForcedLinkTracking = 0;
return
} else
s.b.removeEventListener("click", s.bc, false);
s.eo = e.srcElement ? e.srcElement : e.target;
s.t();
s.eo = 0;
if (s.nrs > 0 && s.useForcedLinkTracking && e.target) { // THIS IS THE ANTI-ADBLOCK CHECK
t = e.target.target;
if (e.target.dispatchEvent && (!t || t == '_self' || t == '_top' || (s.wd.name && t == s.wd.name))) {
e.stopPropagation();
e.stopImmediatePropagation();
e.preventDefault(); // BOOM. NO NAVIGATION
n = s.d.createEvent("MouseEvents");
n.initMouseEvent("click", e.bubbles, e.cancelable, e.view, e.detail, e.screenX, e.screenY, e.clientX, e.clientY, e.ctrlKey, e.altKey, e.shiftKey, e.metaKey, e.button, e.relatedTarget);
n.s_fe = 1;
s.bct = e.target;
s.bce = n;
}
}
})I'll play around to see if the script that's attaching that click listener should be getting blocked (that'd solve the issue without having to whitelist).
Sorry again for the misdiagnosis. :)
Yep I've seen that code often when that specific issue occurs. I think it's Google Analytics, will see if I can narrow.
@gorhill SiteCatalystCode_H_17.js appears to be the file: link.
That, and whatever mnginteractive is:
<script language="JavaScript" src="http://extras.mnginteractive.com/live/js/omniture/OmnitureHelper.js"></script>
<script language="JavaScript" src="http://extras.mnginteractive.com/live/js/omniture/OmniUserObjAndHelper.js"></script>
Confirmed that blocking SiteCatalystCode_H_17.js resolves the anti-adblock behavior issue (so clicking works).
Forget about mnginteractive — the analytics are provided by omniture (more associated terms include: Adobe Marketing Cloud/SiteCatalyst).
I'm having a hard time tracking down the culprit. This site is bloated beyond belief, it's scary.
One thing that work is disabling inline script fixes the problem, and page become fast, except that it probably break other stuff. But it can be read all fine.
@gorhill so you don't think it's SiteCatalyst?
What's the domain to whitelist? I am using dynamic filtering to quickly bypass the static filters.
It's one or more out of these:
www.sltrib.com 2o7.net * allow
www.sltrib.com crwdcntrl.net * allow
www.sltrib.com doubleclick.net * allow
www.sltrib.com google-analytics.com * allow
www.sltrib.com googleadservices.com * allow
www.sltrib.com googlesyndication.com * allow
www.sltrib.com googletagservices.com * allow
www.sltrib.com mnginteractive.com * allow
www.sltrib.com newsinc.com * allow
www.sltrib.com quantserve.com * allow
www.sltrib.com scorecardresearch.com * allow
Will narrow now. Edit: needed:
www.sltrib.com mngi.112.2o7.net * allow
www.sltrib.com scorecardresearch.com * allow
This is it.
It's 2o7.net, I'm pretty sure. Sorry; I didn't understand your question initially.
@gorhill the thing is, the SiteCatalyst script is the one that has the anti-adblock tracking stuff in it (it's the one that attaches the click handler). There's already rules in EasyPrivacy and Fanboy to handle some instances of SiteCatalyst.
So it seems like the right answer to make sure that gets blocked.
Am I missing something?
@@||mngi.112.2o7.net^$domain=sltrib.com
@@||scorecardresearch.com^$domain=sltrib.com
Awesome, thanks everybody!
Might want to share the solution with EasyPrivacy maintainers.
@gorhill why is whitelisting the tracking servers a better idea than blocking the anti-Adblock script?
I apologize if I'm missing something obvious.
@chrisaljoudi not a better idea, it's just that trying to be very narrow is very time consuming and something someone who maintain lists as a full time job would do. I just want a reasonable workaround without having my entire life sucked into dealing with filter lists. You can modify the workaround to be more narrow if you want. Keep in mind it's just one site, so I don't see it as big deal to not have the utmost, narrowest possible exception filter.
@gorhill okay, understood. I understand the issue with having to maintain filter lists. Apologies.
Hi. Looking into this.
(By the way, feel free to ping me on Github about any issues in future with my (Peter Lowe's) list.)
Am I doing it wrong? (Just tested with Easylist + Easyprivacy enabled)
Seems that this has been resolved properly. The only option I have to solve this from my end at the moment, is to remove scorecardresearch.com and 2o7.net from my list, which unfortunately I'm not really willing to do as they're major tracking servers. So, whitelisting those domains, for this site, is the right way of resolving this.
I'll try and think about adding some facility for whitelisting domains on a per-site basis from my side, this isn't the first time this has happened.
https://hg.adblockplus.org/easylist/rev/4632e0202a23 should fix it
I'll try and think about adding some facility for whitelisting domains on a per-site basis from my side
Really I have no complain with your filter list, typically the problem is always with a site which prefers to sabotage itself (voluntarily or not) when they can't play with their ad/tracking toys.
From my side I don't mind to provide these workarounds, I see it as my responsibility given that I select the list by default. It does not occur that often, and also, I would need these workaround anyways for other similar hosts file-based lists, like hpHosts, MVPS, etc.
Anyways, what I am just saying is don't worry about whitelisting specifically, by enabling the filter lists by default I accepted to have to fix these cases. I just do it roughly though, as shown by @ryanbr's solution above.
Confirmed that blocking SiteCatalystCode_H_17.js resolves the anti-adblock behavior issue
I was so focused into trying to find the domain to whitelist that I completely missed what you were saying there. Had you said "This exception filter ||sltrib.com/.../SiteCatalystCode_H_17.js fixes the problem" you would have gotten my attention, it would be a mere cut & paste to my filters to try it.
gorhill
changed the title from broken links in Chrome on www.sltrib.com to [EasyPrivacy] broken links in Chrome on www.sltrib.com
To reproduce:
1. go to http://www.sltrib.com/
2. leftclick on any link (like a headline)
3. observe that nothing happens
4. use uBlock icon to disable uBlock for this site
5. reload web page
6. try clicking links -- observe that they are working fine
7. reenable uBlock for this site
8. reload web page
9. try clicking links -- observe that they are broken again
System info:
uBlock filter options enabled: