Track follow/unfollow from twitter follow button with iframe solution

[BinShao1]

Hi,

I am using iFrame solution to put the twitter follow button on my page (just inserted the iframe in markup by myself). I would like to track the actino of clicking on the iframe to follow and unfollow.

I tried to listen to the “message” event and seems nothing be posed back when I use the pure iFrame solution. Is this true?
Is there anyway I can get the information?

Thanks,
Bin

[benward]

Not at present. The current implementation of Web Intent Events is very dependent on our JavaScript being present on both sides—it predates widespread support for the postMessage API. There is something fun, mid-way down my todo list to massively improve this, which will have a knock-on effect of making it all workable through raw iframes. But no timescale on that yet, I’m afraid. We’ve got a lot of higher priority work to get through first (as the common topics of discussion around here might suggest.)

B

[BinShao1]

Thanks Ben.
Do you mind I ask some more details on this?
I think your client JS insert the iFrame; and then I believe the iFrame called postMessage and your client JS listen to “message”. If so, then can I just use my own Javascript and insert the iFrame and then listen to the “message” event? Maybe I should put some special parameter when creating iFrame? Could you please explain what stops this from working?
You may wonder why I cannot use the your client JS directly. I believe your client JS does more than just listen to “message”. That’s the only thing I want. So, I want to use some simplified version if possible.

Thanks,
Bin

[BinShao1]

Let me make this question more specific. Is it possible for me to create the iFrame with some special parameter (or following special requirement to create the iframe), and then the iFrame can send the postMessage for my client code to catch? If so, what is the required parameter?

Thanks,
Bin

[benward]

Hi Bin,

postMessage is just one of the transports we use for Web Intent Events in this version. There’s also a Flash object transport for old versions of IE without postMessage support. We already announced our plan to deprecate (or partially deprecate) IE6 and 7, and being able to update the events architecture to lose that abstraction overhead is part of that decision.

However, because we abstract the messaging over multiple transports, the current payload we send is not part of the documented API (we currently use an implementation of JSON-RPC, fwiw.) This abstraction has an initialization phase, which relies on widgets-js being present in the parent page, and knowing the identity of the frames it creates.

The future implementation will not have any of that overhead. You could likely write code to function with the existing messages, but I can guarantee that it will change.

Ben

[niall]