Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

HTML5 VPAID and AdClickThru event


Hello,

While testing the development of an HTML5 VPAID format, i've noticed that the implementation of the AdClickThru event by JWPlayer 7 doesn't work correctly.

When a clickthrough occurs on the VPAID format, a AdClickThru event is dispatched, with 3 parameters: the URL string to redirect to, an ID for tracking purpose, and a boolean called "playerHandles" that tells to the player if it's in charge or not for open the URL. If the URL parameter is omitted, the correct behavior for the player is to open the Clickthrough URL that was in the VAST object of the ad.

Unfortunately, it seems that when the playerHandles parameter is set to true, and the URL is set to a custom URL, JWPlayer opens both this custom URL, and the Clickthrough URL from the VAST object, resulting in two browser windows being opened. In Chrome, it works correctly (my guess is that Chrome blocks simultaneous window.open calls), but on Firefox and Safari, there are indeed two browser windows opened.

You can test on JWPlayer Ad Tester (http://demo.jwplayer.com/ad-tester/) with the following VAST tag : http://padmasters.contenttoemotion.com/test/vast.php. When clicking anywhere on the video, you should be redirected to centerparcs.fr (the URL specified in the AdClickThru event), but on Firefox and Safari, it also opens a window with kiabi.fr, which is the Clickthrough URL in the VAST object.

It's worth note the this bug is quite similar with a bug i notified on JWPlayer 6 flash version : https://support.jwplayer.com/customer/portal/questions/9927916-vpaid-adclickthru-event
By the way, this bug on the lash VPAID is still not corrected in JWPlayer 7.

Could you please check this problem?

Thanks,
Ben

5 Community Answers

Alex

JW Player Support Agent  
0 rated :

Hi, Ben.

My name is Alex and I am one of the Support Engineers at JW Player. I will be more than happy to assist you with your questions.

The VPAID 2.0 spec from IAB states the following:

The following logic determines how the video player should respond to clicks:
• The event.data.url is optional
• If event.data.playerHandles is true and e.data.url is:
a. Not defined: then the video player must use the VAST element, VideoClicks/ClickThrough.
b. Defined: then the video player must use event.data.url.
• If event.data.playerHandles is false, then the video player doesn’t open the landing page URL. The ad unit is responsible for opening the landing page URL in a new window in this case.

Note: Regardless of the state of the event.data.handles, the video player must request the resource specified by the URIs in the <VideoClicks> and <ClickTracking> elements of VAST when it receives an AdClickThru VPAID event.

The wording is a little weird, but I read that as the playerHandles parameter would need to be set to false in order for the player not to open the specified URL. However, no matter what the value of playerHandles (I believe the note above to have a type where “event.data.handles” is supposed to be “event.data.playerHandles”), the player is always supposed to request resources found in <VideoClicks>.

Now, I took a look at all of the VPAID 2.0 sample ad tags that we have and none of them include URLs in <VideoClicks> elements in the XML itself, so it’s hard for me to test this. However, if you find what I’ve said to be incorrect, please let me know and I will escalate this to the Engineering team.

Thank you.

benben1311

User  
0 rated :

Hi Alex,

Thank you very much for your answer.

I think you are absolutely correct on your understanding of the VPAID 2.0 spec. If event.data.playerHandles is set to false, the ad is supposed to deal itself with the opening of the URL.
However, the problem i was talking about is precisely happening when event.data.playerHandles is set to true: for now, JWPlayer 7 is opening the URL specified in the VAST object, whether event.data.url is defined or not. And if event.data.url is defined, it is opening a second window with that URL.

Following what you said about not having a <VideoClicks> element, i made a test by removing it from my test VAST, and JWPlayer is indeed opening only the URL set in event.data.url.
But i think you'll agree that this behavior is not consistent with VPAID specs, and it should not rely on the absence of a <VideoClicks> element to work as expected. There is nothing specifying that a VPAID ad should not have a <VideoClicks> element, so it might happen from time to time. And this is precisely what happened to me :)

The flash version of this problem is a bit different: JWPlayer always opens the URL from the <VideoClicks> element, even if event.data.url is set, and even if event.data.playerHandles is false. It might be useful to have a similar behavior between flash and javascript versions, even though flash VPAID ads are going to be quite rare.

Thank you,
Ben

Alex

JW Player Support Agent  
0 rated :

Hi, Ben.

I’m going to have to escalate this to our Engineers to see what they say. As soon as I hear back, I will let you know.

Thank you.

Alex

JW Player Support Agent  
1 rated :

Hi, Ben.

I have heard back from our Product team that have agreed that it initially looks like we are not following spec for that specific use case. They are filing this in their internal bug tracker for a resolution in a future version, but I do not have a timeframe for you. You can keep an eye on our JW 7 Release Notes page as we post release notes and bug fixes with every new update.

In the meantime, I would suggest trying to remove the <VideoClicks> URL from any VPAID ad tags as a workaround.

Please let me know if you need any more help or have any other questions.

Thank you!

benben1311

User  
0 rated :

Hi Alex,

Sorry for this late reply, but thank you very much for your help and the follow up. I will check the release notes of the coming updates and test when possible.

Thank you!
Ben

This question has received the maximum number of answers.