I’m having an issue that I can reliably reproduce on the latest iOS on an iPhone 6 and an iPhone XR. I’ve narrowed it down to the adplugin by testing in safe mode. It does not reproduce on a desktop emulator, like Safari> User agent > iPhone.
v2.3.0.beta3 +20
When two or more dfp nth post code ads are displayed the screen will jump around:
In the case above, dfp nth post code is set to 7.
Scrolling to the very bottom will make the screen jump and the Suggested Topics heading will be centered on the screen moving the Want to read more… text down after approximately 1 second.
It looks like the content moves up. Is it because the ad unit is being collapsed? For example, the ad unit started out as 300x250 (your “dfp mobile post bottom ad size” setting), but was resized to something smaller (DFP loaded smaller creative)?
It’s hard to get anything out of that video since it doesn’t show the ad unit.
The ads are not collapsed, and it reproduces even when all of them are ads that were sold directly - at 600x500 (@2x) and displayed at 300x250 - known sizes.
I realize it’s hard to figure out what’s happening from the screen recording because you can’t exactly see what is me scrolling and what is the jump.
Here is an example that shows what happens when an ad is in view, and how the screen jumps when the ad is scrolled out of view:
I’ve this exact experience and I’ve not been able to get to the bottom of it, even after lots of testing and changing of settings.
I’ve tried setting the ad unit size both within Adsense (eg. 300x250) and within the plugin (300x250) and then even using CSS to force the block to be the correct hight, but it still occurs.
I created a blank 300px high DIV and appended it to every 6th post. It made no difference if it was post:before or post:after
api.decorateWidget('post:after', helper => {
let post = helper.getModel();
if (post.get('post_number') % 6 === 0) {
return helper.rawHtml('<div class="my_mobile_below_nth_post">300px div</div>');
};
});
Even with a blank div, the jumpiness still occurred on mobiles.
Now i’m not in any way an expert, but my suspicion is that the when the server tries to server a new batch of posts it calculates post heights before rendering.
It seems that only once the posts are delivered that the api.decorateWidget script kicks in, adding another 300px to the height of the content that was appended to the post stream. The browser then tries to compensate for this overall extra height, jumping the “view” forward an additional 300px.
Some other interesting notes:
the issue does not seem to happen in the Chrome iPhone simulator.
increasing the Nth number to something above around 15 seems to give the browser time to compensate for the new div height of the batch of posts that are loaded. In some threads that I tested, significantly reducing the jumpiness.
It would seem the only real solution would be for a dedicated post container to be added instead of relying on post.decorateWidget. This, as @codinghorror alludes to, is probably what requires major engineering time.
I’ve analysed traffic to my site and about 55% is from mobile phones; not being able to serve ads to them is obviously having a significant effect on revenue and therefore the viability of the community. My 15+ post workaround helps and I’m going to try to server GPT ads that refresh themselves.
