Bug 1911737 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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 declares that it'll accept a tall-and-skinny ad (whether 300x600 or something else similarly-large).

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!
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!

Back to Bug 1911737 Comment 8