-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ad not autoplay in new version of Google Chrome #604
Comments
Hi there - I'm getting an error from your ad tag on that page, "AdsLoader error: AdError 303: No Ads VAST response after one or more Wrappers" Is it still working on your end? I'm testing in Chrome on a Macbook. |
Hi @shawnbuso , Thanks for quick response; i'm work in Chrome 66.0.3359.139 in windows |
Hmm ok it is still working for me on my Macbook, but I will test on Windows as soon as I am able. |
Thanks a lot @shawnbuso |
@shawnbuso , I not know if has relation, but this problem apparently only occurs with ad tag vpaid, if ad tag is vast, run perfectly... I think that problem is related with Issue 341 (#341), but i can't see what i'm doing wrong... |
@shawnbuso , i replicated your sample of autoplay, but only changed ad tag for my, and error continues... Maybe the problem is in adtag, not? |
Are you seeing the issue with our sample vpaid ad? If not then the issue is likely with the VPAID ad you're using. If that's the case, you'll need to reach out to the author of the ad and ask them to fix the issue. |
@shawnbuso no, only with my ad tag, thanks for support! |
Hmm I'm still not able to reproduce this one - I tried your test page on my Windows machine and I still get ads autoplaying without error. Can you make sure that the iframes have |
@shawnbuso , In case of error, i have a first iframe with allow="autoplay", and inside this iframe, i've second an iframe, that don't have allow="autoplay". |
Which iframe are you referring to when you say "second iframe" - can you tell me what the src is? When I look at your sample page I see 6 iframes by the time the ad starts playing. |
@shawnbuso , maybe this print help to understand |
Aha ok - I believe that is part of the IMA SDK's VPAID implementation. I'll talk to the team and see if we can get |
thanks a lot @shawnbuso |
Hi @shawnbuso , you have news from IMA team? |
Yes, they have made this change and it will be included in the next release of the SDK. |
ok, thank you @shawnbuso |
Unfortunately I don't have a definite timline, but hopefully some time within the next week. |
ok, thank you @shawnbuso , if you have more information, can tell me? |
Yep, I'll update here when that goes live. |
also seeing this issue with our VPAID based player. Oddly enough, when using the google VAST Suite tester, the ad will load with copy-pasted VAST, but it wont from URL for the reasons listed above. Our player uses IMA internally too, so maybe this is a "IMA loading IMA" issue. Anyways, hope the fix works. We'll be waiting for it. Attaching a screenshot of the iframe "stack", the middle one doesnt pass the "allow autoplay", and afaik thats an iframe made by IMA for VPAID only: EDIT: this looks like the same issue above, just adding another account for historical reasons EDIT2: Here is a live test case if you need it: https://vast.mathtag.com/?debug=1&exch=brx&id=asfasf&sid=111666111&cid=5324772&price=12&protocol_version=1&aid=123&adverid=123 |
The fix for this is live as of 5/15, so you should no longer be seeing the issue. You should avoid loading IMA within IMA where possible - it's adding another layer of unnecessary complication. |
@shawnbuso is there any way to influence that middle iframe that i highlighted there? Even without using IAM internally for our VPAID player, it still looks like the VPAID loader is not setting allow=autoplay. This would still prevent anything inside the VPAID from using autoplay, right? EDIT (for clarity): the iframe that loads our VPAID already doesnt have that flag set, that would lead me to think anything inside our VPAID could not influence that. |
Could you share your ad tag with me? Thanks! EDIT: Whoops, I see it in the above message. I'll take a look and let you know what we can do. |
I posted it above, buried in some of my messy edits. But here it is: Another really odd thing: the URL seems to have this issue, but if I copy and paste the VAST contents of the URL (in the VAST test suite in this case), it works fine. Maybe the autoplay fix wasnt applied for URL loading path? |
Actually, are you able to replicate this in our sample player? It times out there. |
Seems to do the same. The logging is a bit weird on our VPAID player, but if I put a breakpoint on the error callback, i can see I get the same internal error I was getting on the vast suite test page: EDIT: this vast URL is the same-ish creative but has slightly more logging, but you still need to dig and breakpoint to get to the internal error that is actually thrown: https://vast.mathtag.com/?debug=1&exch=brx&id=asfasf&sid=111666111&cid=5727627&price=12&protocol_version=1&aid=123&adverid=123 |
I'm still having an issue with your tag - if I test it on our sample page linked above it errors out with "VAST media file loading reached a timeout of 8 seconds." |
Here's a creative that does VPAID wrapping through MOAT: They seem to use some (unknown to me) VPAID magic to play the video file in the content iframe, and not in the "vpaid iframe". Going to dig around through the VPAID spec again... but off the top of your head, do you know what VPAID mechanism they could be using? Seems very strange that you could influence any content outside the VPAID iframe. |
@shawnbuso oh weird... if you go to the URL directly, do you get back VAST? If you check the network monitor, can you see which asset its timing out on? |
If you set your VPAID mode to INSECURE it can influence the parent page, but it's ENABLED by default which does not allow that. That most recent tag is working for me, so I can try to see what's going on there. |
Great, sorry I should have sent you the nocache version. Was a newer creative, might not have gotten to PAO by the time you used that link. Here's a screenshot of whatever MOAT is doing (this was on the same simple tester you linked earlier): They're doing something really strange. That video element is definitely outside the VPAID iframe... I have no idea how thats even possible. Sorry to bother you so much about this, it's been hurting our delivery pretty bad and we're at a loss. We would have gone through our AdX rep (we're MediaMath, a DSP partner), but I feel like this tech might be too far removed from that team... EDIT: actually, it looks like the VPAID iframe isnt sandboxed from the player itself. Not sure if thats by design, or if MOAT is just using loopholes in IMA to place stuff outside of the iframe. They are a viewability vendor, so I think they do all sorts of stuff outside of the iframe that they probably shouldnt be allowed to do =\ |
@shawnbuso sorry to bug you, any new findings here? We're trying to determine our best next course of action, just wanted to get a feel for this issue and if theres been anything obvious thats stuck out so far. thanks! |
Hi there - I do have an update, actually. It looks like we were only setting |
Ok @shawnbuso , thanks a lot for support! |
@shawnbuso thanks for the update and support! 🍰 |
Hi all, The fix to add Thanks, |
Ok @shawnbuso , one more time, thanks a lot for support! |
Hi,
My ads after April of 2018 because Autoplay Policy Changes of Google Chrome, don't autoplay.
My ads call two iframes, in the first allow autoplay, but the second one, not, you can see in:
http://rr.sapo.pt/videojs/imagoogle2.html
My player is videoJs, ad plugin is Google IMA...
Can help me?
Thanks
The text was updated successfully, but these errors were encountered: