Closed kizzard closed 3 years ago
@idettman thanks for the review. Any timeline for a possible merge?
@idettman Can we get a merge here?
thanks @mkendall07 . Can we get a release? We developed this patch as a fix for a publisher using the CDN hosted release.
Oh Hey Jeremy - didn't realize that was you :). @jsnellbaker usually does these releases so just tagging him here.
Thanks Matt (& Jason)!
@kizzard - where is mraid.js supposed to come from? We suspect this is causing problems because it's not available in all environments.
@bretg As per spec, I believe the rendering SDK or delivery ad server should provide mraid.js. From the 3.0 spec:
2.2 Ad Control Ad designers that expect ads to make use of MRAID must invoke the mraid.js script before the ad is loaded (see section 3 on initialization). Once called, the ad container can inject the MRAID JavaScript into the ad file.
The creative is not expected to provide it. The code in this MR is designed to fall back gracefully if mraid.js is not available or otherwise fails to load, and uses a simple pixel trigger instead of MRAID. There are several layers of fallback functionality provided.
Back in the day, the ADTECH ad server used to literally scan the creative code for the string mraid.js
to decide whether or not to inject it - so perhaps burying it in a CDN hosted file is not helping matters, but I would have expected Google's detection to be more advanced.
As an aside, I have debugged a HAR log of a failing MRAID creative delivered by PBS on IOS provided by a client (probably a similar issue you are hearing about) and running it locally, the MRAID error was being triggered in the creative's mraid code itself, not the PUC burl code which fell back to basic pixel triggering. Just an anecdote but thought I would mention it.
This adds MRAID 1-3 viewability support for triggering the bURL. This is an attempt to cut down discrepancies. Note this is my first time writing MRAID code so would appreciate a thorough review if anyone has expertise.