So, as part of my blackhole hosts file that automatically blocks ad & site tracking, I figured out that stats.adobe.com is linked to 127.0.0.1 in my /etc/hosts file.
Is anyone in Adobe tech support aware that this breaks your entire forums site for both Chrome and Safari?
The two urls that kill all ability to click a link on the forums.adobe.com website are:
They appear to try and report back everything they possibly can about the browser, including what plugins, user screen size, browser window screen size, etc.
'boots, you're on your own! If you block Adobe's web site, Adobe's web site isn't going to work. It's really that simple.
Knocking out web sites by forcing their IP addresses to 127.0.0.1 (localhost) in your hosts file is not really a good idea.
It is always an "at your own risk" kind of activity, and you should never be surprised that it breaks something.
While I agree with you in part, it's pretty bad programming on somone at Adobe's part to assume the stats server will always be up.
Everyone out there using Chrome or Safari is going to experience the same thing that I am if that ever stops responding. Which it will eventually. No web hosting is ever entirely successful.
Plus, it's the only forum that this occurs on and it only started occurring recently—like as of the last update by Adobe, I think. It just took me a while to get annoyed enough by it to sit down and figure out what the cause was.
So it's a bug report as much as it is an uncommon configuration.
OK, I win. Add this to your AdBlock manual filters list. (And as a bonus, unbreak Apple's website too.)
So, it turns out this may be a 100% valid bug report after all!
Got this feedback on the Reddit Apple Forum when I posted up about it:
Encountered this same issue recently on a client site, and the problem is actually a change Adobe deployed in the s_code file around v25.2-25.4.
Apple needs to change "s.useForcedLinkTracking=true" to false in the config section of the s_code, otherwise the s_code click event handler goes fubar and nothing will work on the page in Google Chrome if the s.trackingServer and s.trackingServerSecure aren't returning the proper response or are unreachable - which sounds like what's happening here if you route them to localhost.
Bad on Adobe for deploying buggy code so widely used, bad on Apple for not adequately unit testing, even if it is an edge-case.
it's pretty bad programming on somone at Adobe's part to assume the stats server will always be up.
Pure speculation on my part, but as the Adobe Forums are powered by, and hosted by Jive, I would say that they might be culpable.
Alas, it affected (infected?) the entire Adobe website later on. And recently, Apple implemented it site-wide too, which is what finally prompted me to get irritated enough to figure out which specific JS includes were involved and that blocking them would fix the issue.
Again, it's not even so much that they're trying to do metrics as the fact that they're doing it so poorly and with an underlying assumption that the secondary metrics server will never be unavailable. Even a simple test by the script on page load to verify that it can reach the second server—either before adding the click listener or if afterwards such that an error alert pops up when the user clicks a link instead of sitting there like a bump on a log—would be a big step forward.
Let John know so he can either report is to Jive. Or pay heavey boots to go to jive to slpa'um up side the head and show how to fix this screw up.