Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to implement A4A (AMP ads for AMP pages) #3534

Merged
merged 64 commits into from Jun 30, 2016
Merged

Changes to implement A4A (AMP ads for AMP pages) #3534

merged 64 commits into from Jun 30, 2016

Conversation

bobcassels
Copy link
Contributor

This implements infrastructure to support AMP Ads for AMP Pages (A4A) as outlined in #3133. This is not ready for general use yet but rather initial work on implementing an A4A experiment. In particular, there is currently no public signing service. An example implementation for a specific ad network is at https://github.com/google/amphtml/tree/a4a-adsense. However, ad networks may wish to wait to implement their own A4A integration until a public AMP creative signing service is available.

This is a no-retagging change: existing publisher pages should continue to work as written, with unchanged behavior.

Considerations:

  • AmpA4A is an abstract class providing functionality shared across ad networks seeking AMP ads for AMP pages capability. Networks will need to extend and implement abstract functions.
  • AmpAd (tag <amp-ad>) serves as a loader which will add either the 3p or a network-specific A4A extension element as a child. The 3p implementation (named AmpAd3PImpl) implements the same functionality as the original AMPHTML <amp-ad> tag, and is included with the amp-ad extension bundle to ensure no change in latency.
  • The decision to use the A4A implementation is made via lookup of predicate functions based on the ad type attribute. Networks can choose not to use A4A, in which case 3p will be used. If an ad network does not register a predicate, the implementation defaults to the existing 3p ad implementation. (That is, existing ad networks will continue their current behavior, unless the network implementers take positive action to change it.)
  • The response to the CORS XHR ad request will be privately cacheable allowing for it to be rendered within a cross-domain iframe by creating an iframe whose source equals the ad URL.
  • AMPA4A will render the creative to the page in one of the following methods:
    • If the creative does not include signature or signature is not verified: creative is rendered within cross domain iframe (should hit browser cache) on layoutCallback using the same constraints as a 3p ad.
    • If the creative is verified as AMP and the browser supports Shadow DOM (e.g., Chrome): creative is rendered as soon as it is verified and is inserted within shadow root in the publisher page. Shadow DOM ensures CSS isolation.
    • If the creative is verified as AMP but the browser does not support Shadow DOM (e.g., Safari): creative is rendered as soon as it is verified via cross domain iframe.

TODO:

  • Add more unit test coverage
  • AdSense and Doubleclick-specific implementations to be provided in later PRs

'ads/**->src/log.js',
'ads/**->src/mode.js',
'ads/**->src/timer.js',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be whitelisting these for everything under ads, or only for specific modules? (More specifically, the mode.js whitelist here subsumes the one for traffic-experiments.js only, below.)

const slotTop = slot.y + (viewport ? viewport.y : 0);
const slotLeft = slot.x + (viewport ? viewport.x : 0);
return formatFixedWidthInteger(slotNumber, 2) +
// ad slot top, in 1/5 viewport height units
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: +2

@cramforce
Copy link
Member

Alright, made it through a first pass :) Very impressive and awesome CL.

@tdrl
Copy link

tdrl commented Jun 29, 2016

@jridgewell Okay, we have merged to master, run our tests, cleaned up lint, and cleaned up types. The Travis build still finds check-types errors in src/service.js, but I'm pretty sure that those are independent of us.

As far as I can tell, we're ready for you to push the merge button.

Thanks for all your help!

@cramforce
Copy link
Member

We will need to get the build green.

I can fix the compilation errors for you (because things are still so early and these are very hard to fix). But for now, add the files that don't compile here
https://github.com/ampproject/amphtml/blob/master/build-system/tasks/compile.js#L212
and file an issue for me.

There are also
gulp presubmit errors that you can whitelist.

And there appear to be test failures.

@tdrl
Copy link

tdrl commented Jun 30, 2016

Yeah... The compilation system seems a bit... Difficult. Every time I update one set of files, I get brand new errors in other files (some of which I know we haven't touched). E.g., initially it reported a pile of type errors in src/service.js and 3p/environment.js. When I whitelist those in compile.js, it then discovered a bunch of errors in ads/google/utils.js and ads/google/traffic-experiments.js. As I'm beginning to fix those, I'm now getting errors in src/document-state.js.

It's hard to see how we could have caused some of these errors, since I'm virtually certain that we didn't touch those files. So I'm guessing that they were pre-existing and just weren't revealed until this run? Which means they're in production now?

Regardless, we'll fix what we can and whitelist the ones that we're pretty sure we didn't cause.

Terran Lane and others added 14 commits June 29, 2016 22:11
  - Changed element-stub to insert lower-case version of tag name.
  - Removed (deprecated?) test that insert-extension only inserts amp-ad/amp-embed -- not sure why that restriction was there in the first place.
  - Changed cid test to check amp-ad-3p-impl, rather than amp-ad, because the cid will be written to the child / delegate node rather than the parent.
It is causing problems with presubmit checks. So deal with this part later.
@cramforce cramforce merged commit 825bc9c into ampproject:master Jun 30, 2016
jonasmattsson1 added a commit to widespace-os/amphtml that referenced this pull request Jul 5, 2016
* master: (236 commits)
  trim all the columns (ampproject#3894)
  Refactoring: Turn private custom element methods into functions. (ampproject#3882)
  Lower the load priority of ad shaped iframes. (ampproject#3863)
  JsDoc fix (ampproject#3892)
  Add screenshots for Opera to AMP Validator extension. (ampproject#3866)
  Fix renaming of generated JSCompiler_prototypeAlias variable. (ampproject#3887)
  fix typo in amp-sidebar.md (ampproject#3833)
  Validator Roll-up (ampproject#3885)
  [CryptoService] Leverage browser native Crypto API to hash strings. (ampproject#3850)
  Size update (ampproject#3883)
  copy amp-ad docs to builtins (ampproject#3879)
  move doc to extension (ampproject#3878)
  [amp-experiment] Exposes isDismissed() method in AmpUserNotification (ampproject#3832)
  fix action-impl warning on dist (ampproject#3867)
  Add params for microad (ampproject#3827)
  Fixed some A4A tests. (ampproject#3859)
  Updates to colanalytics vendor config for amp-analytics. (ampproject#3849)
  Changes to implement A4A (AMP ads for AMP pages) (ampproject#3534)
  Addresses comment left over from PR#3841 (ampproject#3853)
  Expose submit event with on=submit:el.action syntax. (ampproject#3739)
  ...
if (data.width !== undefined) {
newWidth = Math.max(this.element_./*OK*/offsetWidth +
data.width - this.iframe_./*OK*/offsetWidth, data.width);
this.iframe_.width = newWidth;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bobcassels I'm wondering why we changed

this.iframe_.width = data.width;

to

 this.iframe_.width = newWidth;

See the code before the change.

Was it intentional to cope with something?

cc @zhouyx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#4840 is trying to revert this logic back as we think it's probably a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants