Ad-Block Plus rendered many pages useless after update 10/28

[fhd]

Thanks, was able to reproduce it on adobe.com with the following filter:

Code: Select all

http://stats.adobe.com/b/ss/*

Will look into this.

[mapx]

another example
forum/viewtopic.php?f=2&t=13143

[mapx]

@fhd, any good news ?

[greiner]

Until this issue has been resolved blocking those scripts (all from Omniture) fixes the issue on those sites:

Code: Select all

https://www.bahn.de/common/view/static/1367323865/js/lib/omniture/s_code.min.js
http://wwwimages.adobe.com/uber/js/omniture_s_code.js
http://www.chip.de/js/omniture_somtr_code_vH.25.js
http://www.pcworld.com/www.pcw/js/analytics/omniture/pcwmw-pcworld/s_code.js

[MonztA]

Blocking s_code.js is known to cause issues though.

[MonztA]

Well, that's weird. Now this same is happening on Firefox with EasyPrivacy on http://www.chip.de/ as well. It does work on bahn.de, adobe.com and pcworld.com though.

Added a blocking rule for chip.de for now...

[fhd]

So I've begun to investigate this properly. The issue on adobe.com is still reproducible - if a single specific tracking pixel is blocked, no links work anymore:

Here's a filter for blocking just that tracking pixel:

Code: Select all

http://stats.adobe.com/b/ss/mxmacromedia/*

Blocking the other one from stats.adobe.com doesn't mess anything up. Blocking the same tracking pixel on Firefox does not reproduce the issue.

This is going to be difficult to debug, I fear we're running into a bug in Chrome here

Well, that's weird. Now this same is happening on Firefox with EasyPrivacy on http://www.chip.de/ as well. I does work on bahn.de, adobe.com and pcworld.com though.

Which resource in particular needs to be blocked to reproduce this?

[MonztA]

If both of these pixels are blocked:

Code: Select all

http://omniture.chip.de/b/ss/chipdedesign/*
http://omniture.chip.de/b/ss/cxochipde-prod/*

(don't forget to disable ||chip.de/js/omniture_somtr_code_vH.25.js in EasyPrivacy)

[fhd]

Yup, definitely reproducible in Firefox, exact same behaviour. Means this is not a Chrome bug (although I'm curious why I couldn't reproduce it on adobe.com with Firefox).

Both the tracking pixels on chip.de and on adobe.com have similar URLs, so I bet they're using the same tracking system. Where the other workarounds you had to add for similar URLs?

[MonztA]

I think there haven't been added any other workarounds except for chip.de as far as I know (if that's what you meant).

We could test it with pre 28 Oct 2012 builds but it seems dev builds before 30 Oct are no longer online. Could you ask Wladimir if he still has them or older release builds?

[fhd]

Just tried revision dd020cd4c94a from October 26. The issue is reproducible on chip.de.

I think we'll have to find out a bit more about this tracking system before we can figure out what the issue is. I'm not sure how to debug this.

[MonztA]

Just tried revision dd020cd4c94a from October 26. The issue is reproducible on chip.de.

This one is still newer than 1.3 and it seems it started with that release version. Could you test bdab36d28ab9 (ABP version 1.2) on adobe.com, pcworld.com and bahn.de?

[fhd]

It's a bit hasslesome to get 1.2 to work, because we're using APIs there that have been deprecated and removed by now.

However, investigated this a bit more, and it really is caused by the tracking system (Omniture). It prevents navigating away from the page when a particular tracking pixel is blocked.

We can block the script of that tracking system, as suggested by greiner:

Code: Select all

http://www.chip.de/js/omniture_somtr_code_vH.25.js

I could debug that script and look into what in particular is causing this, but I doubt that we have any other options than to (1) Block the script or (2) Unblock the tracking pixel.

The fact that the issue is not reproducible in Firefox on some sites could be because of webkit specific code (I think I've seen some in there), or maybe the root cause is an exception that's handled differently in Chrome than in Firefox.

Do you think this is worth investigating? Don't really think so.

[MonztA]

What if we could test 1.2 with a Chrome version that was current back then?

I would do it myself if knew how to build 1.2 from the repository (or could you just send me the .crx file?).

[fhd]

Sure, I sent you a 1.2 build. Might be a bit tricky though, there are no official older versions of Chrome, and it'll silently update itself at the first opportunity. So the first thing you need to do after you find and install an old version is to disable automatic updates.