Supporting Breakout Expandable Adverts

[AParsonsADITION]

I have attempted to build the Adplayer into Breakout Expandable adverts and I have come across the problem that the Adplayer will not render and function properly in the parent if the Adplayer CSS and $ADP are not available.

Possible solutions:

[Solution 1] The Javascript and CSS files can be inserted into the parent head element if they do not exist. [Problem] The names / urls for the Javascript and CSS files are not currently none to the $ADP in the iframe.

[Solution 2] Instantiate a new $ADP using a constructor and inject the CSS styles into the parent. [Problem] The Adplayer does not provide a constructor to create the $ADP. The CSS styles are not known and/or the URL to the Adplayer Javascript and CSS Files.

[Solution 3] Set the parent.$ADP = $ADP and write the iframe styles into the parent head element. [Problem] When the Same instance of the Adplayer exists in two window environments there will be loop situation created as the Adplayer in the two windows will be removing and adding items to itself. The check would need to be built in to prevent this loop condition on collecting the privacy information. The Iframe styles may overwrite the parent styles causing unexpected layout problems in the parent page

So I would like to find out how can we solve this problem to create the $ADP and the CSS Styles in the parent in a safe and effective manor?

[ingridgraefen]

Can you please explain what you mean by Breakout Expandables? I guess that this is an ad delivered in a friendly iframe, inserting itself into the parent.

[AParsonsADITION]

Yes, when delivering expandable adverts for example on Microsoft or Dowjones websites, the expandable advert needs to render in the parent just before the IFrame.

The problem is when the parent does not contain the $ADP environment and the CSS therefore Adplayer will not render.

The quick solution I have created was to make parent.$ADP = iframe.$ADP and copy the Iframe CSS information into the parent. I also had to prevent the $ADP.Registry object from pulling privacy information from itself which is the case with it tries to pull parent privacy information which it results in an endless loop.

The Ideal solution would be to have a single constructor for the AdPlayer which would create the $ADP and sub objects as well as create the CSS rules in the target window.

[ingridgraefen]

Maybe I don't fully understand the problem, But shouldn't this just be handled the same way as for all privacy buttons.

Each ad must

• check if the script (and css) is available in the environment where it wants to reside
• if not so, load the files, and wait until the script is accessible
• instantiate the adplayer if necessary
• register privacy info, and so on.

All these steps are always required because even a simple ad may be delivered from an adserver iframe tag.

Breakout expandables know that they have to operate on the parent, so they know where to insert the adplayer script, and where to instantiate or look for the $ADP object.

[AParsonsADITION]

This would mean that the banner script creating the Adplayer will need to include the Adplayer JS and CSS in the parent and wait for the script to load before moving all the registered privacy information in the iframe $ADP to the parent $ADP.

This means we would be relying on AdServers to correclty handle this situation for the Adplayer to render correctly.

Would we be happy with that solution?

[andreasberenz]

We think Ingrid is right. $ADP should not be moved through different windows.

So the best solution for now is to keep the code as it is.