Amphtml: DFP ads incorrectly being resized to values of height/width overrides

[mjrusso]

Summary

When height and width overrides are specified for DFP ads (via data-override-width and/or data-override-height), the <amp-ad> element is (incorrectly) being resized to match the override size.

This is causing an issue in production right now with ads on Telegraph’s site.

Details

Here’s what users are currently seeing:

Vs. the expected result:

Direct link to this page (note: ads are geotargeted to the UK):

http://www.telegraph.co.uk/news/2016/09/14/ruper-murdochs-news-uk-to-be-censured-for-misleading-parliament/amp/

The affected <amp-ad> element on this page looks like this:

<amp-ad
    width = "300"
    height = "75"
    data-override-width = "2"
    data-override-height = "200"
    type = "doubleclick"
    data-slot = "/6582/tmg.telegraph.news/news.2016.09.14"
    json = '{"targeting":{"bs":"news","at":"polar","cms":"gamp","sc":"news.2016.09.14","zn":"news.2016.09.14","pt":"story","pg":"AmmsqYyRTd7s","videosrc":"AmmsqYyRTd7s","gs":["aut_diesel_emissions","biz_business_travel","mastercard_pricelesscities"],"kw":["uk-news","politics","rupert-murdoch","news"]},"useSameDomainRenderingUntilDeprecated":1}'>
    <div placeholder></div>
    </amp-ad>

The expected result is for this <amp-ad> element to be sized at 300x75.

The override-width and override-height parameters are the size of ad unit, as configured in DFP. (Normally the ad width and ad height are the same as the ad unit size, but this is a “native” ad, and can render at any size.) In this case, GPT returns an iframe sized at 2x200; this is a “transport” iframe, and not intended to be visible.

However, the AMP runtime is automatically resizing the <amp-ad> element to the size of this transport iframe.

Given that it may be difficult to reproduce on the Telegraph’s site due to the geotargeting, I quickly threw together another page that replicates the problem.

Link: https://amp.polarmobile.com/dfp-override.html?google_glade=0#development=1

The <amp-ad> element on this page looks like this:

  <amp-ad
               width="500"
               height="100"
               data-override-width="300"
               data-override-height="250"
               type="doubleclick"
               data-slot="/35096353/amptesting/image/static">
            </amp-ad>

Notes:

• To make this sample page a bit more flexible I didn’t include ”useSameDomainRenderingUntilDeprecated":1 in the markup (unlike the Telegraph page), but note the explicit ?google_glade=0 query string parameter.
• Telegraph’s ad is 300x75 with a 2x200 override. This ad is 500x100 with a 300x250 override. The numbers are different but in both cases the outcome we expect is to render an ad that is wider and shorter than the actual ad unit configured in the ad server.
• The example on this sample page is a bit awkward because the creative is a normal banner/ static image at 300x250, but the expected outcome is for it to render at 500x100. Rendering a 300x250 image at 500x100 looks visually wrong, but regardless the example demonstrates the problem.

On this sample page, the expected outcome in the DOM is:

<amp-ad 
    width="500" 
    height="100" 
    data-override-width="300" 
    data-override-height="250" 
    type="double-click"
    data-slot="/35096353/amptesting/image/static" 
    class="-amp-element -amp-layout-fixed -amp-layout-size-defined -amp-layout" id="AMP_1"
    style="width: 500px; height: 100px;">

But what actually happens (when the AMP runtime’s resize request is honoured) is:

<amp-ad 
    width="500"
    height="100"
    data-override-width="300"
    data-override-height="250"
    type="double-click"
    data-slot="/35096353/amptesting/image/static" 
    class="-amp-element -amp-layout-fixed -amp-layout-size-defined -amp-layout" id="AMP_1" 
    style="width: 300px; height: 250px;">

When the AMP runtime’s resize request is denied, the DOM structure looks as expected.

Note: by “AMP runtime’s resize request”, I am referring to a resize request that happens automatically, not via the ad itself calling window.context.requestResize.

Sidenote: Glade / GPT Light does not properly handle width and height overrides either. That’s a separate issue, and I’m happy to file another ticket once the non-Glade issue is resolved.

[jridgewell]

/to @lannka

[lannka]

If I understand it correctly, the bug is:
when width/height override is specified, we should keep the ad slot size unchanged, though it will be different from the actual loaded creative.

If so, I think the fix would be in doubleclick.js . @glevitzky could you take a look?

[mjrusso]

Correct.

There seems to have been a recent change that introduced automatic resizing. It seems that in order for data-override-width and data-override-height to serve their intended purpose, this automatic resizing needs to be suppressed.

Calls to window.context.requestResize should flow through as normal, although if that complicates matters I'd much prefer for that to happen in a follow-up, as this behaviour change is currently causing a real production issue.

[glevitzky]

Fix is on the way: https://github.com/ampproject/amphtml/pull/5165.

[jasti]

@mjrusso Since Native ads can render at any size, why is the container size/ DFP lineitem configured at 2x200? What's special about that size?

[mjrusso]

@jasti in all cases DFP requires a size to be specified (although perhaps the new "fluid" sizing is an exception, but that's relatively new and has its own limitations).

Because DFP requires a size, publishers tend to adopt their own sizing scheme for ads that don't actually have an inherent size. (A common, well established convention is to use a size of 1x1 for interstitial ads.)

Native ads don't have an inherent size either. In this particular case the ad is rendering into a 300x75 container, but the exact same creative can render to containers of different sizes. 2x200 means something special to Telegraph.

[mjrusso]

@jasti (and team) — do you have an ETA on when version 1474668269104 will be released?

This project's README states:

On Thursday the "Dev Channel" release from last Thursday is then pushed to all users.

It sounds like this just missed last Thursday's cutoff — is that the case?

[jasti]

Hey @mjrusso we released 1474668269104 last night.
Yes, we switched dates last Thursday's because of a bug.

[jasti]

Please let us know if the issue persists. Closing.

[adentify]

Unfortunately it would appear that this bug has reappeared.
http://www.telegraph.co.uk/news/2016/10/11/revealed-hard-brexit-will-cost-britain-66billion-per-year/amp/

[jasti]

@adentify are you sure it is this issue?
I don't see the lineitem even returning for the ad call.

Here is a test page: http://output.jsbin.com/bidinokibo

@glevitzky FYI

[mjrusso]

@jasti the ads are geo-targeted to the UK, which is why you aren't seeing any fill.

Note that my original test page (submitted when this ticket was filed) is still active. The page is currently working properly (i.e., there does not appear to currently be a regression): https://amp.polarmobile.com/dfp-override.html?google_glade=0#development=1.

@adentify — we looked into the issue on our end and have identified the root cause. It is not related to this bug (or, more generally, to a bug in the AMP runtime). Ryan Cole is composing an email with more details.

[geoffreybr]

@jasti I still got the same problem on the articles of Rue89 Strasbourg. For example (as far as I know there is no geotargetting here): http://www.rue89strasbourg.com/ouverture-marche-noel-operation-securite-113877/amp#development=1

The amp-ad is defined like that:
html <amp-ad width="300" height="250" data-override-width="320" data-override-height="50" layout="fixed" type="doubleclick" data-slot="/16916245/rue89strasbourg.com/div-gpt-ad-top"></amp-ad>
If we look at the actual DOM, we see that the the <amp-ad> and contained iframe wrapper is properly sized. But inside this first iframe, the actual DFP iframe is wrapped in a 320x50 <div> that limits its size. So, on our pages, we have a big 300x250 white square with a small 320x50 part of the ad...

Thanks for any help!

Two screenshots to illustrate:

---

Classic article:

---

AMP article:

[keithwrightbos]

@glevitzky please investigate

[glevitzky]

I have a hunch that this is caused by some Glade logic. @mlb7687 Could you PTAL?

If you look here: https://github.com/ampproject/amphtml/blob/master/ads/google/doubleclick.js#L313, you'll find that the Glade code path forces the override sizes on the container, if the override sizes exist. Otherwise, it forces the amp-ad tag primary sizes.

I tried removing these lines and re-ordering the size priority, but in both cases it forces the returned creative image to come out as 1x1 pixel, which I don't understand and assume has something to do with Glade and not strictly AMP.

[mlb7687]

@geoffreybr it looks like the creative being served is 200x200 and is targeting a 320x50 slot using size overrides. This probably works fine on a standard web page with GPT aside from causing a bit of reflow. AMP does not support this sort of behavior, but does have alternatives you can use instead.

The best option would probably be to utilize the multi-size support AMP allows if you want to target multiple sizes. Another option is to explicitly target 200x200 if that is the ad you want to serve, rather than targeting 320x50.

[glevitzky]

Just to clarify: To use the multi-size approach, the primary size will need to be changed so that neither dimension is less than 200.