Timo mentioned a cool idea being used in VisualEditor, if you've already scrolled down the page by the time crap at the top is ready to load, it prevents a page bump by calculating its own height and subtracting that as a negative scroll offset.
We could use this same method to prevent banner bump if the page has been scrolled.
Disclaimer: I've seen this not work in VE, so take their example code with a grain of salt.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T138177 Content jumps after JavaScript is loaded | |||
| Open | Feature | None | T52865 CentralNotice shifts down page content on load (causes mis-clicks) | ||
| Open | None | T109634 Reduce the "banner bump" (tracking) | |||
| Duplicate | None | T28234 CentralNotice moves content down when a link to a heading is followed | |||
| Open | Spike | None | T107967 Spike: investigate negative scroll offset for cancelling "banner bump" |
Another CN campaign is running now, and there are lots of people complaining about jumping pages again.
In the late-loading-Javascript-era this really ought to be fixed ASAP.
Hi @TheDJ... Can you tell me which campaign you're talking about? Maybe link to some specific complaints? Actual banner loading is about as optimized as it can be without significant changes to our infrastructure... The current FR campaign seems moderately speedy, at least from here... (When not logged in, try this link.) However, the bump is definitely less than ideal when you follow a link to an article section (like this). Thx!!
Probably POTY or WLE and en.wiki for instance, but this information adds nothing really.
...in almost all scenarios, yes. I just thought we might check that some banner wasn't running super-slow impression-delaying JS ;) But yeah, it's unlikely...