What's the issue?

This issue relates to cases where attempts to access the amp context API from a nested 3rd party iframe (specifically DFP) are unsuccessful. Utilizing #6829 works MOST of the time. However there are instances where the "name" property of the DFP iframe is not a JSON string as the solution in #6829 expects it to be. Therefore, the ad creative has no access to the 'ampcontextVersion', 'sourceUrl', etc.

How do we reproduce the issue?

As I've said, the issue intermittent, but happens probably 20% of the time. Using the following URL to test, we can see that on a failure case, window.name returns something like:

"google_ads_iframe_/24156345/mobile_twist/article_amp/inline1_0"

A successful case has window.name return something like this (I omit some values for clarity):

"{ "host":"d-3447962333352148365.ampproject.net", "type":"ix","count":4,"attributes":{"ixId":"218918","slot":"/24156345/mobile_twist/article_amp/inline1","ampSlotIndex":"0","width":320,"height":50,"_context":{"ampcontextVersion":"1510956201635","ampcontextFilepath":"https://3p.ampproject.net/1510956201635/ampcontext-v0.js","sourceUrl":"http://www.twistmagazine.com/posts/tommy-dorfman-13-reasons-why-career-134029.amp"},"type":"ix"}}"

Also notice how the "ampcontextVersion" property is actually nested within attributes._context in the JSON. This is opposed to what #6829 says where it should be at the top level of the JSON string returned by window.context inside the 3P iframe.

Test URL:
http://www.twistmagazine.com/posts/tommy-dorfman-13-reasons-why-career-134029.amp

Step 1: Open the url in a mobile environment.
Step 2: Scroll down to trigger the amp ad to load
Step 3: Use dev tools to see the name property of the DFP iframes.

Why the inconsistency? Is #6829 flawed or is DFP not being implemented correctly? I notice that, in successful case, the DFP tags are GPT Light tags. On fail cases, GPT Light (Glade) is not on the page.

What browsers are affected?

All browsers

Which AMP version is affected?

Amp version: 1510956201635