3

We are having some problems making our html iframe ads mraid compatible. What we would like to do is make a "relatively simple" HTML ad work just fine both inApp as well as in a browser (We want to use mraid.open when mraid is available, and window.open if it is not).

Our current ad tags consist of a javascript document.write of an iframe with an html source hosted by us. We do not control the domain where the javascript tag is executed, and we do not create the HTML source of the actual ad (although we can make modifications to it like including extra scripts) (nor can we impose some type of requirements on the HTML).

To make our ad mraid compatible, we need to include "mraid.js" into the ad. Because the source of the "actual ad" iframe is hosted on our domain, it does not make much sense to include mraid.js in the html of the ad as that would point to some mraid.js version on our domain.

Which is why we have to include "mraid.js" in our tag (which is executed within an iframe "on the other domain" where a specific implementation of mraid.js is possibly available. This results in the actual problem, the "actual ad" iframe cannot reach the resulting mraid object because of cross domain security issues.

I have googled quite a bit trying to figure out how others have handled this problem and I found pretty much nothing, which is why I thought that we might be doing something weird. Is there some other way to include the html banner without putting it in an iframe of its own? I have thought of document.writing the html file itself into the "other domain" iframe although this would require us to update any relative links inside the html to absolute ones (which seems to be impossible to do 100% reliably).

As far as I know it is not possible to make the mraid object available to our iframe(?), which is why the other solution I could think of is making our own "mraid" interface which allows communication between "their" iframe's mraid and "our" iframe. This however seems like a pretty big solution for what I was hoping would be a small problem.

If the mraid interface is the way to go, could someone explain how to set this up efficiently? My current idea is that in my html source I need to get an implemention of every method available in mraid.js and for each method to do a specific postMessage() to the parent window where the "real mraid" method is executed (if mraid is available) and return any potential results back to our iframe with another postMessage().

Any advice would be greatly appreciated.

Michael
  • 31
  • 2
  • Hi @Michael, I'm actually facing the same issue as what you describe. How did you go about solving this ? – noob Mama Jan 29 '22 at 01:50
  • 1
    Hi @noobMama in the end we decided to indeed go with postMessages. Outside of the iframe a listener is set up to listen for postMessages from inside the iframe (like clicks). Whenever it receives a message it will execute the actual corresponding mraid function. Likewise any events sent by the mraid are forwarded via postMessage from outside of the iframe to inside the iframe where they handled accordingly. – Michael Jan 30 '22 at 23:32
  • 1
    It was quite a lot of work setting things up, and I can't say I can recommend it, especially as the main thing it was trying to solve (simple clicks) was already broken in several browsers -although browsers are not the reason why we made the mechanism- these browsers (firefox and chrome on IOS) have decided that opening new tabs is only allowed on direct user input (which excludes the use of postMessage on the user input, and opening the tab on receiving the postMessage). If the inApp environments would do the same thing then the mechanism would be completely useless. – Michael Jan 30 '22 at 23:39
  • 1
    To clarify my first comment a bit more: we're indeed adding a fake version of mraid inside of our own iframe which only sends and receives postMessages from some code outside of our iframe which has direct interaction with the actual mraid. It does work, but we would love to have had a much simpler solution. – Michael Jan 30 '22 at 23:46
  • Thanks @Michael, sorry for the late reply. That's super helpful to know. – noob Mama Mar 17 '22 at 20:42

0 Answers0