Inheritance problems due to asynchronous loading

[ingridgraefen]

Inheritance for nested iframes, and in general for ads that do not find an already existing $ADP, is not working reliably. This happens more often if resources are loaded from the browser cache. It seems to happen more often in Chrome and IE.

This is a major issue because it affects all ads delivered via adserver iframe tags regardless if the actual ads are iframes or redirects.

The reasons are probably:

(a) each window (except for maybe the main window) loads the adplayer script asynchronously Thus there is no defined loading order between the adplayer scripts in various windows

In theory, this could be solved by loading the adplayer scripts always synchronously. This is however undesired because it affects the loading of the ad itself.

Also, because of (b) it would not solve the issue.

(b) In case of redirects or nested iframes the ad code must first load the adplayer script (sync or async). Then add the iframe tag via document.write.

The correct loading order between the outer adplayer script and a possibly also required adplayer script inside this iframe can only be guaranteed if the iframe tag is added only after the adplayer script has been loaded. This is inacceptable.

Possible solution which would also solve https://github.com/labadserver/Adplayer/issues/91

$ADP.Registry.createPlayer creates the button but does not yet merge the panel items. The panel items are only collected (up to the top window) when clicking the button for the first time. This also minimizes the parent accesses.

This approach creates however two problems:

(a) It requires that the fallback button feature be disabled This is probably acceptable

(b) If no item was registered for this button, an empty button is displayed This can be prevented by creating an oba id only when an item is added. This means that the publisher can only define header, footer, ... if he also adds an item.

[ingridgraefen]

Maybe this would be a sufficient improvement:

Let $ADP.Registry.createPlayer wait for 500ms before it tries to collect all items (up the full window chain) and displays the button. This would probably fix the problem for the majority of ads, but not 100%.

This requires that the fallback feature either dies, or gets a higher timeout value.

But it does not help with https://github.com/labadserver/Adplayer/issues/91

[ingridgraefen]

The suggestion with timeout for $ADP.Registry.createPlayer has another positive side effect.

Currently, the privacy button is sometimes visible before the swf or image are loaded, which looks strange. This is less likely with the 500ms timeout.

[andreasberenz]

1. $ADP.Registry.register should not try to pull the Information from parent windows. Only the added information within its window should be stacked and held until createPlayer is called
2. createPlayer / iconClick calls current pullById method for every parent window and keeps their order to be able reconstruct the info order correctly if responses are given at the same time or in wrong order
3. items are merged in iframe's Registry for the current id
4. privacyPanel will be built and shown

If we agree, that the fallback is important for us now, we have to find a solution for the timeout value.

main window -> high timeout direct ancestor -> less high timeout second-degree ancestor -> less less high timeout ...

If we could forecast of the following windows in chain it would be a simple linear equotation

[olwa]

I'm testing a solution i created yesterday. If the script is okey in the ie7 & ie9 (which i test this morning), i post a link to my solution.

[AParsonsADITION]

Why don't we just prevent the addition of duplicate privacy items and use get to retrieve the privacy items from the parent and not pull? This would be a simple option that I feel would handle most of these interesting a-sync scenarios and not delay the retrieval until the info button is clicked.

[ingridgraefen]

We need the delay because privacy info has not necessarily been registered yet with the parent when the button in the iframe is displayed.

[AParsonsADITION]

I was only implying that we dont wait until the button is clicked and the normal delays still apply. With the Registry holding the privacy items of its parents. This will allow all the child nodes of the parent to be reloaded as many times as they need to and no privacy information will be lost by multiple calls to retrieve privacy information.

Currently children only ask the nearest parents so there will be no duplicates but we can ensure this by not allowing duplicates from being registered. I hope this description makes it a bit clearer.

[dhellmuth]

Lab Adplayer Meeting 13.06.2012: -> v1.6

[olwa]

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