1911737 - puckpedia.com - The ads are breaking the page layout if ETP is set to STANDARD or OFF

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile 129.0

Preconditions:
ETP set to STANDARD or OFF

Steps to reproduce:

1. Navigate to: https://puckpedia.com/teams
2. Wait for the ad to load and observe

Expected Behavior:
The ad breaks the layout of the page

Actual Behavior:
Ad is rendered correctly

Notes:

• Does not reproduce in ETP STRICT as the ad is blocked
• Reproduces in Firefox Nightly, and Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/139997

Comment 1

[Daniel Holbert [:dholbert]]

Here's a screenshot from the github issue

I can't reproduce any issues on my Pixel 6a (Android 15) or Pixel 8 (Android 14) in current Firefox Nightly, Beta, or Release.

Raul, can you still reproduce? I wonder if this was fixed on the site's side?

Comment 2

[Daniel Holbert [:dholbert]]

Tentatively closing as WFM based on comment 1, but please reopen if this is still reproducible.

Comment 3

[Raul Bucata]

Attachment: Screenshot_3.png

Comment 4

[Raul Bucata]

Once the ad loads, it seems to break it now on a certain device for me: Oppo Find X5 (seems device dependent with etp standard or off, so the ad loads). If the ad placeholder is empty, it does not break the page

Tested with:

Browser / Version: Firefox Release 130.0 (2016041319-🦎130.0-20240829075237🦎)/Firefox Nightly 132.0a1 (2016044215-🦎132.0a1-20240913100931🦎)/ Firefox Beta 131.0b5 (2016043863-🦎131.0-20240911093639🦎)/ Chrome Mobile Version 126.0.6478.186/ Edge 126.0.2592.86/ Opera 75.1.3978.72329
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density) (not reproducible)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density) (reproducible)

Comment 5

[Daniel Holbert [:dholbert]]

Thanks. That's odd/interesting that it's reproducing in a device-specific way.

For what it's worth, I tested every Oppo phone model that BrowserStack has available for me to test (A78, A96, Reno 8T 5G, Reno 6, Reno 3 Pro), and I wasn't able to reproduce this on any of them. (Tested using Firefox-that-BrowserStack-has-installed which is v127.0.2; and I tested with ETP at both standard and off.)

Looking at the screenshots of the broken rendering in e.g. comment 3: it looks like ad container element (the element with a gray-background and a black bottom and top border) is ending up too short, and the ad is then overflowing onto the content that follows it.

I don't immediately see how that would happen except via a site bug where they're occasionally adding a different set of CSS classes or styles to that element or something. Locally for me, that element looks like this:

<div class="pp_ad-fullwidth pp_ad-mob">

...and those classes give it these styles -- note the explicit height: 304px in particular which should make this element plenty tall for the sorts of ads that I'm seeing there:

element {
}
.pp_ad-fullwidth.pp_ad-mob {
[ ...]
  height: 304px;
  width: 100%;
  border-top-width: 1px;
  border-bottom-width: 1px;
  padding-bottom: 12px;

If I locally add max-height:10px to that element (or similar), then I can end up with a rendering that's similar to the broken screenshots that Raul's posted. So I wonder if there's some condition where the site is inadvertently doing something along those lines.

Raul: since I can't repro locally on any of the phones I've tested (including the Oppo ones I've got access to), I've got two last ideas for how to reason a little bit about what might be going wrong:
(1) could you attach a screencast showing a broken pageload in its entirety? It'd be helpful to be able to see how this^ container element appears as the page loads.

(2) If it's not too much trouble, it'd be great to capture a performance profile with the bad pageload, which might have some clues. You can do that by tapping the about-firefox-logo to enable debug menu and then scroll to the very bottom of settings and tap "start profiler", and accept the default Firefox profiler-settings-preset. Then, trigger a bad pageload (or a few), and then return to Firefox settings and tap "Stop profiler" (at the very bottom), and then tap "Upload Profile", and then paste the profile URL (which ends up in your clipboard) here. Thanks!

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

Looking at the screenshots of the broken rendering in e.g. comment 3: it looks like ad container element (the element with a gray-background and a black bottom and top border) is ending up too short, and the ad is then overflowing onto the content that follows it.

Aha, maybe the container element is just as tall as it always is (304px tall) and the ad itself (which gets inserted into it) is just extremely tall? Looking at the screenshot in the github issue, it does look like there's a very tall-and-skinny ad there rather than a "portrait-oriented" (shorter-than-300px) one; and maybe that's true on the left half of Raul's screenshot in comment 3, too (I can't immediately tell how tall the ad is since it looks like we're scrolled down a bit and so the top of the ad is clipped there; but it does look taller than the ad image that I'm seeing when I load this page locally.)

The ad content here is an iframe with width="300" height="250" attributes. I can synthetically reproduce something like the bad-rendering (in both Firefox and Chrome) if I add a border to that iframe and then increase its specified height to 750 or similar. (The actual ad content doesn't change its height, but the border does suddenly jut down into the content that follows.)

Comment 7

[Daniel Holbert [:dholbert]]

Continuing down the rabbit-hole from comment 6, assuming we're somehow getting an ad iframe that's too large... I'm trying to figure out how the size of the iframe is determined, in case it's controlled by some API that's potentially-different in Firefox for whatever reason.

The iframe here is generated by
https://securepubads.g.doubleclick.net/pagead/managed/js/gpt/m202410280101/pubads_impl.js

Specifically, there's a line there e = a.render(); and the iframe is generated inside of that, with a width/height size determined by a.l which in my case is Array [ 300, 250 ]

Looking around for Google documentation on where ad-iframe-sizes can be suggested/customized, it looks like that happens via a call to googletag.defineSlot() which passes in an array of allowable ad sizes, as documented here. I found a call to that method in the https://cdn.tpdads.com/tag-v4.min.js script that we're using here (where S is googletag I think):

      (i = i.concat(t.bannerSizes)),
[...]
      if (_t(n, gt) || _t(t.st, ft)) {
        if (fe) return null;
        e = S.defineOutOfPageSlot(r, _t(n, gt) ? S.enums.OutOfPageFormat.INTERSTITIAL : n)
      } else e = S.defineSlot(r, i, n);

So then the question is, where does t.bannerSizes come from? That seems possibly like it's a step closer to a source-of-truth, because when I hit this line in desktop Firefox, I've got t.bannerSizes including some very wide sizes (900px wide or so), whereas in responsive design mode, the banner sizes are on the order of 300px wide.

Looking further up in this script, I found a section that might define a collection of allowable banner-sizes, which does notably include some tall ones:

    Ai = {
      banner: [
        '970x250',
        '970x90',
[...]
        '320x50',
[...]
        '300x600',
        '300x250',

300x250 (at the end there) is what I normally get when I load the page; but the line immediately before that has 300x600 which would definitely be too tall, if the site ended up choosing that.

I'm not sure yet how (or even sure that) it chooses among this list of sizes to construct t.bannerSizes before our call to defineSlot above -- that's the next mystery I'm poking into here...

Comment 8

[Daniel Holbert [:dholbert]]

I dug a bit further but I'm stopping since this is all a bit speculative and the JS is minified & spread out, which all makes investigation quite slow-going and of-dubious-value.

Bottom-line, the best explanation at this point is that the site's ad-selection logic probably declares that it'll accept a tall-and-skinny ad iframe (whether 300x600 or something else similarly-large), which then overflows beyond the 304px height that they actually have set aside for the ad.

This might be a size from the banner array partially-quoted in my previous comment, or it might be taken from the P.slots_full dictionary-of-arrays that gets used and copied into the variable _ later in the script -- its entries look a bit like this (quoting my console) -- note several h: 600 tall sizes:

>> P.slots_full[12].n
"dsk-box-ad-e" 
​>> P.slots_full[12].s
0: Object { w: 300, h: 250 }
1: Object { w: 300, h: 600 }
2: Object { w: 120, h: 600 }
3: Object { w: 160, h: 600 }

...or the size might come from somewhere else entirely, who knows. But in any case, the site here seems to declare a specific fixed height for its ad container, which is the height: 304px quoted above, and they have content immediately following it, which trivially gets overlapped if their ad-selection-logic happens to choose a taller image.

Without better insight into their ad-selection-logic and without being able to reproduce locally, I think we're a bit blocked from investigating further.... so this might want to move to webcompat:blocked.

A screencast and a perf profile still might have a helpful breadcrumb, though, so leaving needinfo open for those. Thanks in advance!

Comment 9

[Daniel Holbert [:dholbert]]

(This is almost certainly not a layout bug, though; it's likely a bug in the site's own JS that it uses to determine the acceptable sizes-of-ads that it'll request from ad-bidders. That might be dependent on UA-sniffing or other browser-specific characteristics, or it might be something more arbitrary.)

Comment 10

[Raul Bucata]

Once the ads are loaded, it does not reproduce anymore

Tested with:

Browser / Version: Firefox Nightly 134.0a1 (2016053319-🦎134.0a1-20241030214633🦎)
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Operating System: Oppo Find X5 (Android 13) - 1080 x 2400 pixels, 20:9 ratio (~402 ppi density)

Comment 11

[Daniel Holbert [:dholbert]]

Ok! That's good news, thanks.