iOS cannot seek content after ad plays

448 views
Skip to first unread message

Steven Barnett

unread,
Jul 27, 2020, 3:59:01 PM7/27/20
to Interactive Media Ads SDK
1. Which SDK are you using (Android, iOS, HTML5, Flash)?

HTML5

2. What ad tag are you using in your request?

https://pubads.g.doubleclick.net/gampad/ads?
sz=640x480&iu=/124319096/external/single_ad_samples&ciu_szs=300x250&impl=s&gdfp_req=1&env=vp&output=vast&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ct%3Dlinear&correlator=


3. Are you able to reproduce this issue using your ad tag in the sample app (AndroidiOS) or the Video Suite Inspector (HTML5Flash)?

Surprisingly, no

3a. If not, please provide an app or website with which we can reproduce this issue.


4. What steps must we take to reproduce your issue?

Run a basic HTTP server on localhost hosting the simple IMA SDK example and load the page from an iPhone or iPod. The issue does NOT reproduce on iPad. Watch the pre-roll, then attempt to seek forward in the content. There are two ways you can do this: Either modify the HTML of the page to add the "controls" attribute to the video, and update the CSS to give the ad display container "pointer-events: none" (this way you can click on the video to seek), or open a developer console and attempt to set the currentTime attribute directly. In either case immediately after seeking it will jump back to where you were before.

I've traced the source of the issue and found it occurs in ima3.js -- specifically in the function that begins "k.yf = function(a) {"

This function seems to get bound to the "timeupdate" event when a "startTracking" message is sent by the bridge HTML. It should get unbound when a "stopTracking" message is sent, but this "stopTracking" message is not being sent on affected iOS versions.

It's not clear to me why the VAST inspector page does not experience the issue. I will try to investigate the JavaScript on that page and see what it's doing differently.

Steven Barnett

unread,
Jul 27, 2020, 4:00:59 PM7/27/20
to Interactive Media Ads SDK
Note that the behavior seems very similar to an issue reported 4 years ago: https://groups.google.com/u/1/g/ima-sdk/c/lTVG-8kTu2M

That issue was allegedly fixed in 2017. I don't know if it was an iOS update or an IMA SDK update that caused it to start happening again, or if the new issue is unrelated.

I do know that we first started noticing the seeking issues in December 2019. At the time we assumed it was our fault, so we disabled ads on iOS until we had time to investigate. I began investigation this week and have concluded the issue is not within our code, as it can be reproduced using the sample code provided by Google.

IMA SDK

unread,
Jul 27, 2020, 10:50:50 PM7/27/20
to steven....@blueframetech.com, ima...@googlegroups.com
Hi Steven,

Thank you for reaching out to us. We're already aware of this behavior, the team is actively working on providing a fix for this issue. I'll update the bug ticket already raised regarding this issue and rest assured that I'll come back to this thread as soon as possible.

Regards,
Arnaud Casame
IMA SDK Team


ref:_00D1U1174p._5004Q22ZTDm:ref

Steven Barnett

unread,
Jul 28, 2020, 3:33:10 PM7/28/20
to Interactive Media Ads SDK
I have figured out the reason the VAST inspector works and the sample code does not.

The VAST inspector does not pass the content video element to the constructor for the AdDisplayContainer. As such, the IMA SDK creates a new video element for playing ads. The seek listener is then bound to this new element.

The downside to this solution is that on iOS only one player can be fullscreen. So if you play mid-roll ads with this setup then the content will pause you will hear the mid-roll, but not see it (as it's playing in a different video element which is not fullscreen).

A possible workaround is to give the content player the "playsinline" attribute and then disable fullscreen. This allows all ads to play normally without breaking seeking, however it comes at the obvious cost of no longer supporting fullscreen.

IMA SDK

unread,
Jul 28, 2020, 8:23:55 PM7/28/20
to steven....@blueframetech.com, ima...@googlegroups.com
Hi Steven,

Thank you for providing additional insights with regards to the issue. I updated the bug ticket already raised regarding the seek content issue, the team is going to look into it and rest assured we will update you once we have our findings.


Regards,
Arnaud Casame
IMA SDK Team


ref:_00D1U1174p._5004Q22ZTDm:ref

Steven Barnett

unread,
Aug 14, 2020, 10:26:07 AM8/14/20
to Interactive Media Ads SDK
I just wanted to follow up on this thread and see if there has been any work done to address the bug on iOS in the HTML5 IMA SDK.

As a reminder: The issue seems to come from the "bridge" page not sending the "stopTracking" message to the SDK, so the "seeking" event listener is not getting unbound from the player when the ad ends. This seeking event listener seems to exist to prevent skipping ads (when you attempt to seek forward, it automatically seeks back to where you were previously)

IMA SDK

unread,
Aug 14, 2020, 2:35:43 PM8/14/20
to steven....@blueframetech.com, ima...@googlegroups.com

Hi Steven,

 

I work with Arnaud and will assist you. Thank you for following up with support. We don’t have an update for you at this time, but we will come back to this thread as soon as we have more information.

 

Regards,

Aryeh Baker

Maverick Chacón

unread,
Sep 30, 2020, 7:00:39 PM9/30/20
to Interactive Media Ads SDK
Hello, 

Is there any update regarding this error? 
I confirmed that we are facing the same error, it seems that the timeupdate still bounded after ad finishes, this of course bumps the playback to star over again once any midroll ad finishes, even worse it prevents us to seek the playhead.  

Regards, 
Maverick 

IMA SDK

unread,
Sep 30, 2020, 11:00:33 PM9/30/20
to mchac...@gmail.com, ima...@googlegroups.com

Hi Maverick,

Thank you for your message. I’m afraid we do not have an update yet regarding this issue, but let me follow up this with the team. I’ll let you know once I received feedback.

Regards,

Google Logo
Sherwin Diesta
IMA SDK Team
 


ref:_00D1U1174p._5004Q22ZTDm:ref

Maverick Chacón

unread,
Oct 19, 2020, 1:31:14 PM10/19/20
to Interactive Media Ads SDK

Hello, 

Just want to follow back on this since I have no seen updates on their release notes  https://developers.google.com/interactive-media-ads/docs/sdks/html5/client-side/history  

Is there any alternative solution you would suggest for this, while your team confirms/fixes this error. 

Regards, 
Maverick 

IMA SDK

unread,
Oct 19, 2020, 3:34:42 PM10/19/20
to mchac...@gmail.com, ima...@googlegroups.com
Hi Maverick,

You can try  calling  `google.ima.settings.setDisableCustomPlaybackForIOS10Plus(true)` before creating the AdDisplayContainer and disable the video controls during an ad break. This may help your use case.

Regards,

Google Logo
Aryeh Baker
IMA SDK Team
 
 

ref:_00D1U1174p._5004Q22ZTDm:ref

Steven Barnett

unread,
Oct 19, 2020, 5:32:14 PM10/19/20
to Interactive Media Ads SDK
The `google.ima.settings.setDisableCustomPlaybackForIOS10Plus(true)` settings disables full-screen support on iOS, so that solution is a no-go for us. Our application is primarily viewed in full-screen.

We first noticed issues with iOS ads back in November and at the time, having higher priority concerns, we just disabled ads on iOS platforms. In July we finally sat down to address our iOS bugs and discovered the issue came from the IMA SDK. It's now been 3 months since we reported the issue to Google, and almost a year since the issue first arose in the IMA SDK. At this point we've given up waiting on Google to fix it and we began writing our own "mini IMA SDK" to meet our needs. We aren't building out ad pod support or VPAID support (two features we don't need) but we've got ads playing now by doing our own VAST parsing, video download, and tracking URL code.

IMA SDK

unread,
Oct 19, 2020, 11:26:15 PM10/19/20
to steven....@blueframetech.com, ima...@googlegroups.com

Hi Steven,

We understand your concern. Let me check with the team to see if there’s an alternative workaround for this other than setting the setDisableCustomPlaybackForIOS10Plus to true. We will let you know for any updates.

Regards,

Google Logo
Sherwin Diesta
IMA SDK Team
 


ref:_00D1U1174p._5004Q22ZTDm:ref

juliu...@googlemail.com

unread,
Oct 27, 2020, 7:28:29 PM10/27/20
to Interactive Media Ads SDK
Hi Guys,

this issue still exists with setDisableCustomPlaybackForIOS10Plus to true.
Is there any DOM listener which prevents from seeking?
Is there any workaround to remove this listener.

IMA SDK

unread,
Oct 28, 2020, 3:58:00 AM10/28/20
to ima...@googlegroups.com

Hi there,

Thank you for your message. I would just like to confirm the type of ads are you using here, are using skippable ads?

Regards,

Maverick Chacón

unread,
Oct 28, 2020, 5:59:45 PM10/28/20
to Interactive Media Ads SDK
We used both linear and skippable ads, all of them from your sample ad tags listed here https://developers.google.com/interactive-media-ads/docs/sdks/html5/client-side/tags 

IMA SDK

unread,
Oct 29, 2020, 2:58:58 AM10/29/20
to mchac...@gmail.com, ima...@googlegroups.com

Hi Maverick,

Thank you for your response about the ad types and for your confirmation that the issue is still occurring even with setDisableCustomPlaybackForIOS10Plus set to TRUE. I’ll share this to my teammates to check further and will let you know for any updates.

Just to add, the reason why I asked you about the ad type you are using is because there are some limitations when it comes to skippable ads especially when you’re disabling the custom playback via the setDisableCustomPlaybackForIOS10Plus() method. You can check out the link below for more information.

https://www.googblogs.com/new-custom-playback-apis-for-ima-html5-and-mobile-safari/


Regards,


Maverick Chacón

unread,
Dec 11, 2020, 9:56:01 PM12/11/20
to Interactive Media Ads SDK
Hey there, 

Just want to follow up on this one as I haven't heard since October. 
as a side note, we prompt our customers to use setDisableCustomPlaybackForIOS10Plus method as workaround, however they want to get the full trueview skipable ads experience on their players, which of course cannot be done using this workaround. 

thanks

IMA SDK

unread,
Dec 13, 2020, 11:58:27 PM12/13/20
to mchac...@gmail.com, ima...@googlegroups.com

Hi Maverick,

Thank you for getting back to us. Let me relay your concern to my teammates to check further. We will keep you posted.


Regards,


IMA SDK

unread,
Jun 10, 2021, 2:53:41 PM6/10/21
to mchac...@gmail.com, steven....@blueframetech.com, ima...@googlegroups.com
Hi Maverick,

I tried replicating this seek issue in our simple sample on iOS 14.5 and I was able to seek after an midroll ads in our advanced sample which is set to play fullscreen using our VMAP - Pre-roll Single Ad, Mid-roll Standard Pods with 5 Ads Every 10 Seconds for 1:40, Post-roll Single Ad. Are you able to reproduce this issue anymore?

Regarding skippable ads in iOS Safari, there is the order of setup for the SDK:

google.ima.settings.setDisableCustomPlaybackForIOS10Plus(true);
const adDisplayContainer = new google.ima.AdDisplayContainer(adContainer, video);
const adsLoader = new google.ima.AdsLoader(adDisplayContainer);


Our skippable ads for iOS example disables custom playback before creation of the adDisplayContainer and that sample is the source of correct implementation for disabling custom playback on iOS. It appears that disabling custom playback cannot be fully functional anymore if not set before the creation of the adDisplayContainer and adsLoader.

Regarding having skippable ads with fullscreen, unfortunately that isn't possible, as described in this blogpost.

Regards,

Google Logo
Aryeh Baker
IMA SDK Team
 


ref:_00D1U1174p._5004Q22ZTDm:ref

Maverick Chacón

unread,
Jun 18, 2021, 5:13:30 PM6/18/21
to Interactive Media Ads SDK
Thanks, 

Seems like the order matters. After moving the  `google.ima.settings.setDisableCustomPlaybackForIOS10Plus(true);` prior the adsLoader initialization  the error described dissapeared. 

Thanks,
Maverick 

IMA SDK

unread,
Jun 20, 2021, 11:51:58 PM6/20/21
to mchac...@gmail.com, ima...@googlegroups.com
Hi Maverick,

Thank you for updating us, and I'm glad that the issue has been resolved. Allow me to share your findings to the team as well.

Feel free to get back to us if you have any other concerns related to IMA SDK.

Regards,
Google Logo
Teejay Wennie Pimentel
IMA SDK Team
 


ref:_00D1U1174p._5004Q22ZTDm:ref
Reply all
Reply to author
Forward
0 new messages