Archive for March, 2008

Facebook Beacon: Cool but Kind of Scary

Posted on March 28th, 2008 in facebook | No Comments »

A friend of mine was playing an online flash game called Boxhead Zombie Wars and a message suddenly popped up on the lower right corner of his browser window stating that “Kongregate is sending this to your Facebook profile”. I couldn’t believe it so I started playing the game myself and a few minutes into it, sure enough:

Kongregate Facebook popup

“Super freaky!” was my initial thought. Followed closely by “How did they know I’m on the Facebook?”, “How do they know my name?”, and “Is facebook tracking my ip and giving others access to it?”. And lastly, “OMG!”.

I logged into Facebook and the story was there – although awaiting my approval to be posted. This last bit makes me feel a lot better but I still find the whole thing freaky.

Facebook Beacon is the name of this feature. A quick search at Wikipedia explains: “Beacon is a part of Facebook’s advertisements system that sends data from external websites to Facebook, ostensibly for the purpose of allowing targeted advertisements, and allowing users to share their activities with their friends.”.

Facebook’s About Beacon Page

Issue with Omniture’s Site Catalyst Form Analysis Plug-in

Posted on March 11th, 2008 in JavaScript, Omniture | 6 Comments »

Update: To further illustrate my discussion below I have created an example page with nothing but a basic form and Omniture code with the Form Analysis plugin. Clicking the submit button with Omniture enabled should alert the Form Object but notice in Firefox, Safari, and Opera the Window Object is instead alerted. Internet Explorer alerts the Form Object in both cases as it should.
How to fix the issue: Omniture has to fix this issue. Somewhere in their code they need to change a direct function call to use that function’s apply method instead so that they can keep the this reference targeting the same object.

I wanted to write about an issue I’ve been debugging with a particular sport’s team site and the issue ended up stemming from a conflict in Omniture’s Site Catalyst Form Analysis Plug-in with existing form validation code on the site. The form in question had a hard-coded event listener that (simplified) looks like this:

<form id="addForm" onsubmit="return validateForm(this)" method="post">
     // form contents here

The function validateForm is being passed one argument, this, which is a reference to the form it’s attached to. This function validates the form and returns true or false (with false halting form submission.) When the Omniture code runs, it removes any listeners on the form and ques them up to run after Omniture’s listener. Since the Omniture code is running in the global namespace (window object) the this keyword of our form validation function is now referencing the global window object instead of the form it was originally attached to. Unfortunately, because of it’s obscured nature – I couldn’t find the specific mechanism directly causing the issue in their code during my Firebug debug session. I have tracked it down to the Form Analysis 2.0 plugin, which tracks form success/abandonment rates. I can see that when the Omniture code is in the page all references to this change to the window object, which is pretty horrific since this is the basis of writing object-oriented code.

Since I can’t see Omniture’s code to fix it, the only end solutions are:

  • Removing all references to the this keyword in the site-specific code
  • Remove the Omniture plugin.

I’m pushing for the latter as developers shouldn’t have to code around an analytics tool, and the Omniture guys really need to fix this. I’ve looked around and found a related Omiture conflict with this in the jQuery JavaScript framework:

“Conflict with Omniture javascript”

As well as Dean Edward’s addEvent2 script:

“Anyone know why this code would conflict with Omniture’s SiteCatalyst javascript files?”

For the above two scenarios, you may be able to move the omniture include above the other js includes so that it loads first, in my situation, I don’t have access to certain parts of the site so my options are limited. Hopefully this page will serve as a resource to others though, who also run across it.

Cookie tab for Firebug

Posted on March 6th, 2008 in Firebug, General Web Dev | 2 Comments »

If you’re like me, and you’re constantly using document.cookie to check your cookie settings in Firebug Console – life just got a little bit easier with a Firebug Extension by Jan Odvarko called Firecookie that let’s you view and manage cookies. Sure their’s plenty of cookie plugin-ins for Firefox and the built-in cookie manager is fine, but for the speed of having a tab right there in your Firebug console it’s a great time-saver.

Firecookie Screenshot

Another great feature is that whenever a cookie value changes it’s logged in your console – a feature especially good for troubleshooting (but perhaps an extra option for turning that off would be nice.) I like seeing what kind of values the sites I visit are using.

Jan has also wrote up a tutorial on extending the Firebug console with your own creations – this is something I’m definitely looking forward to experimenting with. I also look froward to seeing other creative addons. Nothing beats Yahoo’s YSlow Firebug extension, though. Something I’ll have to write more about in a future entry.