this is the example mentioned above.
http://www.gameswf.com/webgl/test_ads2/
1. play the first ad
2. iframe the second page
3. play the iframed ad
It doesn't have 100% replicability

Thanks for filing the issue!

Unable to reproduce the issue on reported chrome version 68.0.3440.75 using Windows 10 with the steps mentioned below.
1. Launched Chrome
2. Navigated to http://www.gameswf.com/webgl/test_ads2/
3. Clicked on play for first ad
4. After ad is played, clicked on Iframe
5. Played the second ad
We didn't observe any hang in browser, attaching the screen cast of the same. Similar behaviour is seen in M66(66.0.3359.181) too.

@Reporter: Could you please have a look at the screen cast and let us know if we have missed anything in the process. Any further inputs from your end may be helpful.

Deleted: 867333.mp4 2.2 MB

	867333.mp4 2.2 MB View Download

Hi! Thanks for the fast response.
As I said, it's not 100% reproducible.
It happens to hang on the first try, but its behavior varies.
This is my recording of the bug. 
https://youtu.be/pRWMTcLCaCs it was too big to upload

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the report!  Sanil, maybe you're able to help us spot what's going wrong here?

I can repro this fairly frequently on Windows 67.0.3396.99, 68.0.3440.68, and 70.0.3501.2, similar to what was shown in the video as comment 4.  (It wasn't repro'ing for me on ChromeOS 67.0.3396.99.)

Here's what it showed in the DevTools console after clicking Play in the iframe:

recycle stuff
ads.js:66 create ad display container
ads.js:25 ads loader Rs {K: false, I: Array(1), B: Jd, $b: Rs, Pa: null, …}
ads.js:34 add listeners for ads manager and error
ads.js:43 create ads request
ads.js:57 Y {slotId: 1386429124, adTagUrl: "//pubads.g.doubleclick.net/gampad/ads?sz=730x400&i…s=%26is_gameid%3D12is_pubid%3D2&corelator=1595763", linearAdSlotWidth: 640, linearAdSlotHeight: 360, forceNonLinearFullSlot: true, …}
ads.js:59 SEND REQUEST


If I try again and get a successful ad, the DevTools console looks like this:

recycle stuff
ads.js:66 create ad display container
ads.js:25 ads loader Rs {K: false, I: Array(1), B: Jd, $b: Rs, Pa: null, …}
ads.js:34 add listeners for ads manager and error
ads.js:43 create ads request
ads.js:57 Y {slotId: 316099503, adTagUrl: "//pubads.g.doubleclick.net/gampad/ads?sz=730x400&i…s=%26is_gameid%3D12is_pubid%3D2&corelator=6665750", linearAdSlotWidth: 640, linearAdSlotHeight: 360, forceNonLinearFullSlot: true, …}
ads.js:59 SEND REQUEST
ads.js:81 ads manager loaded
ads.js:148 ad loaded
ads.js:158 ad started

(Note that there are sometimes CORB warnings when the ad plays, but those are false positives, and they're gone in M69+ as expected, due to the fix in  issue 844178 .)

Sanil, can you repro using http://www.gameswf.com/webgl/test_ads2/ and the steps in comment 1?  We'd love to figure out why things are breaking down.

I can also repro on Mac Canary 70.0.3502.0 with Site Isolation enabled (less frequently than on Windows, but it still happens), and I haven't seen it yet on the same version without Site Isolation.

Comparing the network requests, the working and non-working cases both load http://imasdk.googleapis.com/js/core/bridge3.223.0_en.html, https://s0.2mdn.net/instream/video/client.js, and https://adservice.google.com/adsid/integrator.js?domain=server.ideastudios.ro after clicking Play in the iframe.  The working case goes on to load a data:image/gif URL and then a URL like the adTagUrl one seen on the console:

https://pubads.g.doubleclick.net/gampad/ads?sz=730x400&iu=%2F14162828%2FAFG-Ingame&gdfp_req=1&env=vp&output=xml_vast3&unviewed_position_start=1&hl=en-US&cust_params=%26is_gameid%3D12is_pubid%3D2&corelator=2390447&sdkv=h.3.223.0&sdki=3c0d&correlator=4088760240046117&scor=2463080119061247&adk=925050916&media_url=http%3A%2F%2Frmcdn.2mdn.net%2FDemo%2Fvast_inspector%2Fandroid.mp4&u_so=l&osd=2&frm=2&sdr=1&is_amp=0&adsid=NT&jar=2018-07-25-18&vpa=auto&vpmute=1&afvsz=200x200%2C250x250%2C300x250%2C336x280%2C450x50%2C468x60%2C480x70&url=http%3A%2F%2Fwww.gameswf.com%2Fwebgl%2Ftest_ads2%2F&ged=ve4_td12_tt0_pd12_la12000_er8.8.158.308_vi0.0.600.800_vp100_eb24427

That URL doesn't load in the non-working case.  Sanil, what part of the code normally requests that URL?

From the debugging I made I observed that once the top page sets up its listeners, some of the ad requests from the iframe are caught by the top page listeners and not by the listeners set up in the iframe.
I hope it's a track you can follow to isolate the issue.

Another thing that I observed is that in chrome 68 beta I can't reproduce the bug. https://youtu.be/LjSNtKno9EQ

Comments 10-11: Thanks for the observation.  Can you be more specific about which listeners you mean?  (In theory, I could see there being conflicts if some of the frames had the same names, but in that case I would imagine that having multiple instances in the same page wouldn't be supported in general, regardless of Site Isolation.)

Also, I'm still able to repro the bug in 68.0.3440.68.  (It just doesn't happen every time.)

Sanil and I are making a bit of progress repro'ing the bug in a more controlled environment, which might let us see more about what's failing.

I'll tentatively take ownership of this to keep things moving forward, which I think will involve figuring out which part of the ad isn't working, and then mapping that back to a behavior change in Chrome.

I thought I had repro steps for this in a debug setting (with a very similar frame tree) that would tell us more about why the ad was failing, but it appears my steps show a problem that occurs with or without Site Isolation.  That means it's probably not the same thing, but I'll post it here anyway for reference:

1) Visit https://google-developers.appspot.com/interactive-media-ads/docs/sdks/html5/vastinspector_5ba2007beb4682c53068740df57bb596.frame?hl=en
(This page already has an IMA iframe, so we don't need to start playing the ad here to trigger the issue, as in comment 1's repro steps.  Note that the bug doesn't repro if you use a simpler URL here, like https://google-developers.appspot.com.)

2) Inspect the body tag in DevTools and uncheck the "overflow: hidden" style (within .devsite-framebox) so that you can scroll the page.

3) In the DevTools console, enter this to create a cross-site iframe for hosting a nested IMA (then scroll down to see it):
f = document.createElement("iframe"); f.src = "https://csreis.github.io/tests/cross-site-iframe.html"; document.body.appendChild(f); f.width=1024; f.height=768;

4) Change the DevTools console menu from "Top" to "cross-site-iframe.html" and enter this into the console to load the nested ad debug page:
navFrame("https://imasdk.googleapis.com/prerelease/js/3.222.0/")

5) Enter the following in the "Ad tag" box:
https://pubads.g.doubleclick.net/gampad/ads?sz=730x400&iu=%2F14162828%2FAFG-Ingame&gdfp_req=1&env=vp&output=xml_vast3&unviewed_position_start=1&hl=en-US&cust_params=%26is_gameid%3D12is_pubid%3D2&corelator=2390447&sdkv=h.3.223.0&sdki=3c0d&correlator=4088760240046117&scor=2463080119061247&adk=925050916&media_url=http%3A%2F%2Frmcdn.2mdn.net%2FDemo%2Fvast_inspector%2Fandroid.mp4&u_so=l&osd=2&frm=2&sdr=1&is_amp=0&adsid=NT&jar=2018-07-25-18&vpa=auto&vpmute=1&afvsz=200x200%2C250x250%2C300x250%2C336x280%2C450x50%2C468x60%2C480x70&url=http%3A%2F%2Fwww.gameswf.com%2Fwebgl%2Ftest_ads2%2F&ged=ve4_td12_tt0_pd12_la12000_er8.8.158.308_vi0.0.600.800_vp100_eb24427

6) Scroll down and click "Request+Play Ads"
Nothing plays.

---

As noted above, though, that happens even when Site Isolation is disabled, so it may not be exactly the same bug.  If you use the alternate URL in step 1 (https://google-developers.appspot.com), then the ad plays with or without Site Isolation, even if you inject another IMA iframe into it before step 2.

Also for reference, I was able to repro the original bug (using the steps in comment 1) in a Chrome 64 build with Site Isolation enabled, so it's not a new regression-- just something that Site Isolation seems to be causing.

Please do let us know which listeners/callbacks are getting triggered in the wrong frame, which might help us understand the problem.  Thanks!

As per comment #13, removing 'Needs-Bisect' label.
Please feel to add it back if any bisect information is required from TE end.

Thanks..

Comment 10: Can you share more about which listeners you were referring to, to help us track down the problem?

Hey. I have been debugging for some days the IMA code and inserted a few logs to figure out what's happening.
http://i.prntscr.com/MNeQwu-FTuy0jLn-OK_vzQ.png
Right after the container and the request are created, a listener triggers in the top page IMA. After that, it's a mix of top and iframe postmessages being received.
Here is the recording. https://youtu.be/qwrlFycwyjo
And here is the code. http://server.ideastudios.ro/sandbox/html5/florin/ima_marti/

Tell me if I can provide more info.

I've taken another look at both the original repro and the one in comment 16, but I don't know how to interpret them or figure out which listener is firing in the wrong frame.  damargulis@ is helping to investigate further.

Florin, can you say more specifically which listener is firing in the wrong frame?  I'm not sure how to read your debugging logs.

I was able to reproduce the bug when running chrome version 69 on windows however upon switching to the debug version of the ima sdk code (http://imasdk.googleapis.com/js/sdkloader/ima3_debug.js), the bug goes away and the ad plays fine.  

The difference in the debug version only comes from the compiler rules.  The production version adds "--define=goog.DEBUG=false", "--remove_closure_assets", and several strip_types (http://google3/javascript/closure/builddefs/builddefs.bzl?l=121&rcl=203805121).  It also strips out the loggers (http://google3/javascript/ads/interactivemedia/build_defs.bzl?l=90&rcl=206044217).

This should just mostly be removing loggers and print statements, so my only theory now is that there is some race condition somewhere in the loading code leading to the hang.  

I am debugging on the obfuscated version of IMA, that's why my logs are a little gibberish. I've pinpointed the exact line that makes the difference (http://gamesglue.com/game_core/check/ima4.js : 1164). The Ld function receives messages with different types. At the beginning only "gpt", but it should at some point receive "activityMonitor" (whoever receives the activityMonitor message will receive the ads manager).
It most probably is a race condition, but it's quite hard to debug on obfuscated code.

I would like to mention that we're running into this issue as well, unclear since when or what the exact impact of the problem is. I was able to reproduce the problem with the simple example of the IMA SDK.

More details here: https://groups.google.com/forum/?fromgroups#!topic/ima-sdk/P97yBff6RoI

I've been testing on MacOS High Sierra 10.13.6 - Chrome 69.0.3497.100 64-bit

Comment 21: Thanks for the extra repro case at https://github.com/Prokos/ima-broken-iframe!  I must be missing a step, though-- I tried putting a copy online with a cross-origin iframe at http://csreis.github.io/tests/867333/repro1/root.html, and it's not working.  Do you have a live copy of the repro somewhere?  Or is there an extra step to get it to work?

damargulis@: Let me know if this new case helps, since it appears to be using the debug IMA SDK (assuming we can get it to repro).

Thanks Creis! I'm not seeing ads on my local version anymore either, I'll go through it and see what's wrong. The bug however is still reproduced in your version (and mine), if you open the console, you should see that the requestAd button in the top window properly triggers debug logs from ima_debug.sdk, and the iframed version does not.

The demo is broken because the test ad tag (taken from the IMA samples) is not returning an ad anymore. Replacing the ad tag url in sdk.js with this one works: https://raw.githubusercontent.com/InteractiveAdvertisingBureau/VAST_Samples/master/VAST%204.0%20Samples/Inline_Linear_Tag-test.xml

Another find: if you load the top-level IMA after the bottom-level IMA, everything works. I've added a commented piece of code to my main sample's root.html that does this. 

It's purely loading the bottom-level IMA later that causes the problem, sadly turning this around is not a useable solution for our case :(

Comments 23-25: Thanks for the updated URL.  Unfortunately, I think you're looking at a different issue unrelated to the rest of this bug, and which may be an issue with the page rather than Chrome.  Just to be clear, here's the repro steps I'm following:

1) Visit http://csreis.github.io/tests/867333/repro1/root.html
2) Click "requestAd" in the main frame.
3) Wait for the ad to finish and disappear.
4) Try to click "requestAd" in the iframe, and nothing happens.

This is because there's a div with an invisible iframe above most of the previous iframe, apparently left behind by the main frame's ad.  If you use DevTools, you can delete that overlay div and the button works fine.  The same behavior occurs with and without Site Isolation, and in Firefox as well.  I think the resolution will likely be to update the page so that the leftover div from the previous ad goes away.

Let's focus this bug on Florin's issue and try to come back to comments 19-20.  (If there's another Chrome issue besides that, let's file a different bug for it at new.crbug.com, just to keep this one focused.)

Thanks for having another look, I'm sorry for the crude prototype causing this confusion. This is not about the iframe blocking the usage of the button. You do not need to request the ad in the main frame for the bug to occur, the SDK just needs to be initialised in the main frame. 

1) Visit http://csreis.github.io/tests/867333/repro1/root.html
2) Try to click "requestAd" in the iframe, and nothing happens.
3) Click "requestAd" in the main frame.
4) Confirm that the same code does work in the main frame

Comment 27: Wow, that's weird.  I can't seem to repro that at all on Mac Canary 71.0.3568.0 in my normal profile, but I do see it roughly 2/3 of the time in an Incognito window in that profile.  (Same on Mac Stable 69.0.3497.100.)  Thanks for clarifying!

damargulis@ put together a debug version of ima3.js at //storage.googleapis.com/gvabox/damargulis/iframe/inner/wrapper3.js to help diagnose the bug if we can catch it, and I've got a version of that here:
http://csreis.github.io/tests/867333/repro1/root-debug.html

Unfortunately, neither of us seem to be able to repro the bug using that version (in Incognito or not), so we don't have the extra context that the debug statements would have provided.  If anyone can get a working repro with that version of the SDK, it would help us track this down.

FWIW, I can repro 100% of the time on a local Linux release build with dcheck_always_on.  requestAd in the iframe never works.  Like Charlie, I can't repro this on Mac Canary at all, but I can repro on Windows Canary about 30% of the time.

Also on Linux, for requestAd in the main frame, the ad briefly flashes and then disappears, which doesn't happen on other platforms and also seems surprising.

#29: I can also repro on the debug version on my local Linux build without incognito, though instead of not seeing the ad at all, I see that it flashes briefly and then disappears.  Here's the console output:

Navigated to http://csreis.github.io/tests/867333/repro1/root-debug.html
wrapper3.js:293  [  0.004s] [INNER - ADSLOADER] Constructur
wrapper3.js:293  [  0.006s] [INNER - ADSLOADER] Constructur
wrapper3.js:293  [  0.468s] [ima.gptproxy.GptProxy] Iframe event with unsafe origin received on /tests/867333/repro1/root-debug.html with data: Name: gpt, Type: isGptPresent, Session: *, Data: {"scope":"proxy"}, Origin: https://storage.googleapis.com
vs @ wrapper3.js:293
wrapper3.js:293  [  0.471s] [ima.gptproxy.GptProxy] Iframe event with unsafe origin received on /tests/867333/repro1/root-debug.html with data: Name: gpt, Type: isGptPresent, Session: *, Data: {"scope":"proxy"}, Origin: https://storage.googleapis.com
vs @ wrapper3.js:293
wrapper3.js:293  [  0.731s] [ima.gptproxy.GptProxy] Iframe event with unsafe origin received on /tests/867333/repro1/root-debug.html with data: Name: gpt, Type: isGptPresent, Session: *, Data: {"scope":"proxy"}, Origin: https://storage.googleapis.com
vs @ wrapper3.js:293
wrapper3.js:293  [  0.428s] [ima.gptproxy.GptProxy] Iframe event with unsafe origin received on /tests/867333/repro1/no-iframe-debug.html with data: Name: gpt, Type: isGptPresent, Session: *, Data: {"scope":"proxy"}, Origin: https://storage.googleapis.com
vs @ wrapper3.js:293
bridge3.html:797  [  5.006s] [ima.common.GptCompanionAdService] GPT companion ads service not available.
JK @ bridge3.html:797
bridge3.html:797  [  5.007s] [ima.common.GptCompanionAdService] GPT companion ads service not available.
JK @ bridge3.html:797

<<<I pressed the requestAd button here>>>

wrapper3.js:293  [  8.557s] [INNER - ADSLOADER] requestAds called
wrapper3.js:293  [  8.588s] [INNER - ADSLOADER] requestAds finished
bridge3.html:797  [  8.223s] [ima.loader.AdsLoaderWrapper] Requesting ads using new ads loader.
bridge3.html:797  [  8.225s] [ima.loader.AdsLoaderWrapper] requestAds, processing external request.
bridge3.html:797  [  8.225s] [ima.loader.SequentialAdsLoader] Enqueued new request.
bridge3.html:797  [  8.226s] [ima.loader.SequentialAdsLoader] Starting request from queue.
storage.googleapis.com/gvabox/damargulis/iframe/inner/bridge3.html#goog_484059442:1 Access to XMLHttpRequest at 'https://raw.githubusercontent.com/InteractiveAdvertisingBureau/VAST_Samples/master/VAST%204.0%20Samples/Inline_Linear_Tag-test.xml' from origin 'https://storage.googleapis.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
bridge3.html:797  [  8.281s] [ima.loader.UrlLoader] Failed! retrying without credentials
JK @ bridge3.html:797
bridge3.html:797  [  8.496s] [ima.loader.AdSourceFactory] Creating VastAdSource.
bridge3.html:797  [  8.503s] [VastAdSource] processInlineAd, successCallback with 1 ads
bridge3.html:797  [  8.506s] [ima.loader.AdsLoaderWrapper] dispatchAdsManagerLoadedEvent_, ads.length: 1
bridge3.html:797  [  8.509s] [ima.managers.AdsManagerFactory] createAdsManagerFromAds_, adType: video
bridge3.html:797  [  8.520s] [ima.loader.SequentialAdsLoader] Starting request from queue.
bridge3.html:797  [  8.649s] [ima.managers.BaseAdsManager] Could not display companion ads.
bridge3.html:797  [  8.956s] [ima.vast.VideoAdEventTracker] dispatching event error
bridge3.html:797  [  8.964s] [ima.managers.VastVideoAdsManager] Ad error: null
bridge3.html:797  [  8.968s] [ima.managers.VastVideoAdsManager] Playback error: [object Object] AdError 400: There was an error playing the video ad.
bridge3.html:797  [  8.993s] [ima.common.ErrorUtils] Error play dispatched: AdError 400: There was an error playing the video ad.
JK @ bridge3.html:797
storage.googleapis.com/gvabox/damargulis/iframe/inner/bridge3.html#goog_484059442:1 Mixed Content: The page at 'https://storage.googleapis.com/gvabox/damargulis/iframe/inner/bridge3.html#goog_484059442' was loaded over HTTPS, but requested an insecure image 'http://example.com/error'. This content should also be served over HTTPS.
error:1 GET http://example.com/error 404 (Not Found)
Image (async)
Op @ bridge3.html:277


(I excluded the obfuscated JS call stacks, let me know if those are needed.)

Comment 31: Thanks!  There's a chance that's because of missing codecs in debug Chrome builds.  (I don't see the ad playing in the main frame either.)

(We're chatting offline, and Alex will try a build with codecs to double check.)

#32 is correct: after rebuilding with codecs, I can no longer repro on Linux.  Sorry for the false alarm.  I tried the debug version from #29 and also can't hit a repro with it anywhere.

29: With this debug version everything works perfectly fine on my end as well. 100% of the time.

The original build still never works for me.

I'm on Mac - Chrome 69.0.3497.100

Is there any update on this? Could we get somebody from the IMA team to look at the issue? 

I'm currently considering hosting and using the debug build in production as that seems to fix the problem.

Hi, sorry for the long delay on this issue.  Unfortunately, I can not recommend that as a solution for production.  The link at //storage.googleapis.com/gvabox/damargulis/iframe/inner/wrapper3.js is not stable, and will not be suitable for production purposes.  Domain validation and ad spam checkers will likely prevent this from working for any extended period in production.  

Unfortunately, without a more reliable way to reproduce the bug with local builds of the IMA SDK, getting more context on the issue is difficult and debugging may take some time.  I am continuing to search for a better way to reproduce the issue in a debug environment and will keep you updated on any progress that is made.  

Update: Daniel and I met earlier today and talked through some theories of what might be happening.  It's difficult when we can't modify the Javascript code without causing the repro to stop working, but we've been able to make some progress by setting breakpoints in Chrome's DevTools to see which parts of the code are and aren't being reached when the bug occurs.  (Note: be sure to test on Chrome 69, because we discovered  issue 893364  with setting breakpoints sometimes not working in Chrome 70.)

We found a few lines in the minified source code which correspond to meaningful points in the original source code, and which seem to influence whether the bug occurs.  You can set breakpoints on them after pretty-printing the file, using the "{ }" button.

The most promising is line 11428 of the inner frame's copy of ima3_debug.js.  (Be sure to set the breakpoint in the correct copy of this file-- not the main frame's copy.)  This line is where the inner frame injects its ad iframe into the page.  At least on ChromeOS, setting a breakpoint before that line tends to cause the page to work correctly, and setting a breakpoint after that line tends to cause the bug to occur.  This seems to indicate that if the inner frame creates its copy of the ad iframe first, everything will be fine, but if the main frame creates its ad iframe first, we end up not seeing the load event.  Said another way:

Repro steps:
1) A creates iframe C.
2) A creates iframe B1.
3) C creates iframe B2.
4) No load event for B2.

No repro steps:
1) A creates iframe C.
2) C creates iframe B2.
3) A creates iframe B1.
4) Load event for B2.

To test this theory, I tried creating a minimal repro of these events:
http://csreis.github.io/tests/867333/repro2/main.html
It's possible to set breakpoints in either the main frame or the subframe to cause the "ad" iframes to be created in either order.

Unfortunately, that's not enough to repro the problem-- the load events always occur in my smaller test page, regardless of order.  Daniel also found that the load event isn't a perfect predictor of the problem.  We can hit a breakpoint on line 11551 (inside the load event handler) and still see the bug.

We'll continue trying to spot the difference between passing and failing runs to narrow down what the problem is.

Thanks for the update Creis.

Any progress so far, or anything I can help with? As mentioned before this is quite a heavy problem for us, and it's a little painful that it is going unfixed for such a long period of time.

Thanks for the ping.  I'm reaching out to Daniel to see if we can take another look, since we both got pulled away.  We can try to keep digging, but given how hard it is to repro the bug with any changes, it's been hard to make progress.

Potentially good news: Daniel mentioned that the bug no longer repros for him after a recent change on the IMA side (internal link: b/117597975).  The fix for that bug seems to address a race similar to what we're seeing here (where IMA might start listening to the wrong frame and stop processing events from the correct frame).

I've tried testing http://csreis.github.io/tests/867333/repro1/root.html and the repro from comment 16 and the ad appears to always play for me now.  I've tested in Windows 70.0.3538.67 and 72.0.3590.0, as well as ChromeOS 69.0.3497.120, with none of them showing the bug (despite Site Isolation being enabled).

Can you confirm on your side whether the bug has gone away?

Thanks! Some quick testing on my end on MacOS 69 does now give me an ad every time (as directly opposed to never). This looks great.

I'll also be checking internally whether others can no longer reproduce.

Thanks for the work and support.

I've been having a look at our metrics, and it appears that we have a huge lift in impressions since ±19th of October. 

I cannot follow the internal link you've provided, is there a possibility that you can provide me more details concerning the fix? I'd like to have some idea of the stability of the fix and chance of it re-appearing. We'll be definitely doing damage control for the case if this happens again, but it looks like the negative impact is quite profound.

Glad to hear its fixed!  Thanks for your patience and sorry again for the delay.

It looks like the issue came down to a race condition over communication across the internal IMA SDK iframe.  We were previously using a channel would handle communication for IMA events (such as requestAds), and GPT proxy.  The root cause of the issue came when GPT proxy would send a message before and IMA events.  The first message that got sent was then considered a trusted source, and subsequent messages from other sources would not get through.  We have fixed this issue such that any messages from GPT proxy are handled specifically and do not get marked as the correct origin. We have set up a series of regression tests to ensure that this problem does not come back, and that any other race conditions around this area are avoided.  Therefore it is unlikely that this issue reappears.  If anything similar does reappear please report it right away!  Although it is difficult to say what to do in advance, some possible things to try would be placing slight delays before the creation of the AdDisplayContainer if possible.  You can also try placing a timeout on the requestAds call.  You would still lose advertisements in this case, but the user experience would be able to proceed uninterrupted.  Ideally however this issue should not return, so please report right away if you see anything similar!

Thanks damargulis! This re-assures me that the problem should not re-appear. In terms of damage control I was indeed thinking about timing out the calls, so the user journey can continue in case the SDK is unresponsive.

Cheers!

Fantastic!  I'll mark this bug as fixed (with no need for a change in Chrome). Thanks for the help with the reports, repro steps, and observations!

The NextAction date has arrived: 2018-10-26

Amazing news. I can finally close this tab and stop refreshing it every morning :D
Thanks to everyone involved, IMA developers included.