Inheritance problem when moving iframes between DOM nodes

[ingridgraefen]

Unfortunately, there is a serious problem with inheritance of privacy infos for iframe ads. I hadn't thought about that earlier.

Here is a common scenario: an ad is loaded at the end of a document and then moved via DOM methods into its final position

If an iframe element is moved via DOM methods (appendChild, insertBefore), all browsers except IE<9 make a fresh request for the iframe url. This means that iframe content is loaded again (from browser cache if possible), and javascript actions are performed twice. How much is loaded/executed twice depends on how far the iframe was completed before the iframe gets moved, i.e. unpredictable.

I don't know if any specs require this behaviour, and if so, I don't see why, but this is just the way it happens.

Depending on timing issues, the privacy button in the first load has already retrieved privacy items from the parent and unregistered the parent's oba id. When the privacy button of the second request tries to inherit privacy info, the parent does not have items for the given oba id any more. So sometimes items will be lost in the iframe button, sometimes all items will be showing.

(Of course, this iframe problem causes a lot of other problems too, in particular issues concerning received impressions.)

Maybe, this could be solved by delaying the search for parent privacy items for maybe 200 msecs (would that be enough?). Or else by only stopping the fallback timeout in the parent but not deleting the parent's privacy items.

Either solution poses more timing issues especially with deeply nested iframes, in particular regarding the upwards search from foreign iframes. Items might be doubled because they are still available in parents.

[AParsonsADITION]

When the IFrame is rendered with window.name set with the privacy information then this will not be a problem as the fallback is always the window.name.

The iframe can be created as follows ( just explanation code to aid argument, will not work if you cut and paste ;-) :

<script type="text/javascript">
var iframeName = $ADP.Util.btoa( $ADP.Util.JSON.stringify( $ADP.Registry.getById(obaId) ) ),
      src = 'http://www.iframe.org/advert?oba='+obaId,     //Fake URL
      style = 'position:relative;'
        + 'z-index:' + z + ';'
        + 'background-color:seagreen;'
        + 'width:' + w + 'px;'
        + 'height:' + h + 'px;';

document.write('<iframe name="'+iframeName+'" id="ad-' + sz + '-iframe" src="'+src+'"' + ' style="' + style + '" frameborder="0" scrolling="no"></iframe>');
</script>

The $ADP.Registry.pullById could be used to remove the entry which will mean the only option available to the iframe is the window.name property as the parent entries have been removed.

[ingridgraefen]

There are two problems with the name fallback:

(1) Ad managers receive the ad code from an agency and copy/paste this code into an adserver template. We cannot assume that an ad manager is capable of making such changes to the ad code.

(2) The iframe ad itself might need a name attribute for other reasons.

[AParsonsADITION]

I would not change the timing as this will introduce more timing issues and may impact on the rendering of the fallback button.

If we do not remove the retrieved privacy items from the parent Registry this would allow the privacy items to be retrieved as many times as needed and because only the nearest parent registry is ever asked there will be no duplicate privacy items retrieved by the iframe and the privacy items can be retrieved as many times as needed.

[andreasberenz]

Uh...there we should do some research.

If the iframe's content is loaded twice - and inside the iframe there is a third party tag...this tag would be loaded twice too - I think. So there could be rendered some other ad...sounds like an origin for differences in counting adrequests.

But I think AdPlayer's Issue could be solved in an easy way.

Problem: Moving Iframes within an Iframe's DOM structure seems to be unlikely for me. If the Iframe is moved inside the top window, and adcode will be evaluated twice, the initial oba_ID will be used again but the registry does not hold this information, because another party already pulled the information and an unregister is called.

Solution: if window.$ADP.Registry == top.$ADP.Registry -> do not unregister when information is pulled If we keep this information in the main window, it could be pulled and processed a second time. I do not see any side-effect in keeping the information if there could be found a clear process to handle the timeout for the fallback button. createPlayer could take the responsibility to inform every parent window until top window to clear the timeout for the given oba_id.

[ingridgraefen]

The issue will be solved for us with https://github.com/labadserver/Adplayer/issues/93

because

• the iframe will only be shown after it has been moved
• privacy items are only collected when the user clicks

The fix for issue 93 still needs testing.

[dhellmuth]

will be closed by Oliver Wagner after commiting code

[olwa]

@ingridgraefen Can you test and close this Issue? The new code is pulled in this git.