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

Native ads using rendererUrl do not render within GAM SafeFrame #253

Open
ourcraig opened this issue Feb 10, 2025 · 1 comment · May be fixed by #254
Open

Native ads using rendererUrl do not render within GAM SafeFrame #253

ourcraig opened this issue Feb 10, 2025 · 1 comment · May be fixed by #254
Assignees

Comments

@ourcraig
Copy link

Describe the bug
Native creative are unable to render using the rendererUrl custom renderer scenario via the Prebid Universal Creative as a third-party banner creative in GAM when Serve into a SafeFrame is enabled.

The following SecurityError is thrown from native.js it tries to call renderAd:

Uncaught SecurityError: Failed to read a named property 'document' from 'Window': Blocked a frame with origin x from accessing a cross-origin frame.

Image

To Reproduce

  • Test page: https://codesandbox.io/p/sandbox/972753
  • Set ENABLE_SAFEFRAME to 1 to target a PUC with Serve into a SafeFrame enabled
  • Set ENABLE_SAFEFRAME to 0 to target a PUC with Serve into a SafeFrame disabled

The expectation is that the creative renders in the same way regardless of the SafeFrame

@dgirardi
Copy link
Collaborator

dgirardi commented Feb 10, 2025

I unfortunately do not know the history for this:

// if the current iframe is not a safeframe, try to set the
// current iframe width to the width of the container. This
// is to handle the case where the native ad is rendered inside
// a GAM display ad.
if (!isSafeFrame(window)) {

It looks like a hack where if we are able to determine that the creative iframe is set to have dimensions of 1x1, we force its inner document to have the same width as the outer container. Doing this from saframes would be quite complex and we do not even attempt it.

At the same time, it looks unnecessary - we can just ask the parent to set the iframe to 100% width. I wonder if this was the intent and that code is doing the same thing in a very roundabout way, or if there is some other scenario where looking at the parent's dimensions is necessary.

For now #254 keeps the hack in place (for non-safeframe) but asks for 100% width when the parent is not accessible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready for Dev
2 participants