Doubleclick served a4a ads do not work when loaded in a PWA with shadowdom

[indieisaconcept]

What's the issue?

When loading an AMP document into a shadowdoc as part of PWA, should the document contain an amp-ad of type "doubleclick" which loads an amp4ads based ad, the ad fails to load due to numerous errors related to No ampdoc found for [object HTMLHtmlElement].

How do we reproduce the issue?

A demo is available here: https://d1kvlucx6m02nr.cloudfront.net/

Upon first ( uncached ) load the ad loads correctly as the document is yet to be loaded within the shell container.

However as soon as navigation occurs & the shell container is used the ad fail to load.

1. Navigate to https://d1kvlucx6m02nr.cloudfront.net/
2. Click on "Article 1"

What browsers are affected?

All browsers

Which AMP version is affected?

HTML shadows – Version 1910071803120

Based on previous issues related to PWA, shadowdoc & Doubleclick it looks like there may have a been a regression.

• Test amp-ad works seamlessly when embedded inside of a PWA  #9679
• Fix DFP A4A in PWA errors  #9999

Additionally the a4a ad example loaded via projects example of a PWA is also broken. http://localhost:8000/pwa/

[indieisaconcept]

Just wondering whether this issue is on anyones radar in @ampproject/wg-ads

[jeffjose]

@calebcordry Would you mind taking a quick look?

[indieisaconcept]

Thanks @jeffjose & @calebcordry. FYI I had to replace the ad as it is no-longer being trafficked. I've replaced it with the a4a example.

[mehigh]

I've looked at the demo page myself in the latest Chrome Canary - it behaves in the same way as the screenshot posted here. It's behaving in the same fashion in Safari on OSX, so I can rule this out as not being a browser-specific quirk.

[derekherman]

@calebcordry could you estimate when you would be able to put some headspace around this issue or find someone else on the AMP team that could?

[calebcordry]

@indieisaconcept @mehigh @derekherman Sorry for the delay.

@indieisaconcept Thanks a lot for the example page.

Did some searching and I think this might be related to the work in #22734 @dvoytenko would you mind taking a look?

[indieisaconcept]

@calebcordry thanks. Happy to provide further support/examples as required to assist with getting this resolved.

[dvoytenko]

@calebcordry The #22734 is not launched yet. And based on error stacks I can confirm that this is not in the same codepath.

[calebcordry]

@dvoytenko thanks for checking. I will dig more into this today.

[calebcordry]

cc/ @ampproject/wg-ads

[indieisaconcept]

@calebcordry I had chance to pull down your branch. It looks like the change your proposing in #25321 resolves the issue which is great news.

[indieisaconcept]

@calebcordry great to see this merged. When do you think this could be feasibly released?

[calebcordry]

@indianburger @indieisaconcept While debugging this issue we also found a related issue fixed in #25357. We are currently discussing the risk/reward in trying a cherry pick. I will update here with the resolution. Worst case it would follow the normal AMP release schedule.

[dvoytenko]

Cherrypick is in #25367, so hopefully it can be in PROD sooner.

[calebcordry]

@indieisaconcept Change should now be live in canary. You can opt in at https://cdn.ampproject.org/experiments.html . I tested the new version on you example page, but feel free to test on your own, and let us know if you run into anything unexpected.

[indieisaconcept]

@calebcordry thanks! I can confirm based on testing that I am seeing the same behaviour as yourself with the example page & when testing against our pre-prod environment I am seeing ads load correctly.

[indieisaconcept]

@calebcordry, @dvoytenko just wanted to say thanks for getting this resolved so quickly. I verified again today following the prod release.

[dvoytenko]

@indieisaconcept Thanks for reporting and helping us repro this!

[jeffjose]

Thanks for the quick turnaround on this, @calebcordry and @dvoytenko!