Proposed in Community-Wishlist-Survey-2016. Received 47 support votes, and ranked #26 out of 265 proposals. View full proposal with discussion and votes here.
When a link to a heading, such as http://en.wikipedia.org/wiki/Holam#Pronunciation , is followed, the browser shows the correct heading, but moments later the fundraising banner is loaded and it causes the content to move down, which is quite confusing. I tried it on XP in Firefox, MSIE and Chrome.
Version: unspecified
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T28234 CentralNotice moves content down when a link to a heading is followed | |||
| Resolved | None | T39727 move geoIP lookup back to the head | |||
| Open | Spike | None | T107967 Spike: investigate negative scroll offset for cancelling "banner bump" |
The behaviour is quite random: the first time I tried on Firefox (after re-enabling the centralnotice) nothing happened, then it has always "moved down" as you said; on Chrome it moved down the first time, but moved the page to the top on hard refresh (Ctrl+R) and following refreshes, and returned to the previous behaviour when opening the page in incognito window (on bot incognito and normal window); on Ekiga, it doesn't show the centralnotice, but looks like loads something and brings you to the top of the page.
Someone in fundraising list sais that this doesn't happen with Chrome for him.
I think that moving down the page doesn't make any sense, but bringing you to the top to make you read the banner does, if you're supposed to close it when you've seen it, while moving the page to the top when there isn't anything is a bug (but I suppose it affects only some niche browsers).
I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101130 Ubuntu/9.10 (karmic) Firefox/3.6.13; Chromium 6.0.484.0 (54673) Ubuntu 9.10; Ekiga 2.28.0.
The behaviour is quite random...
Not really, as far as i can tell, the behaviour happens because the central notice is loaded by js independently of the page. So depending on the order of thingies happening in your browser, it will get moved down if the central notice loads after the rest of the page (or whenever fragment identifiers/targets/whatever they're called get processed by the browser). Since the central notice takes up room, so the rest of the page is moved down to make room for it, which is noticeable if you're not at top of the page.
However the ekiga behaviour you describe is quite weird.
...but bringing you to the top to make you read the banner does...
Lets not do that, beyond breaking links to specific sections, that'd just be plain annoying.
Unfortunately, the banner has to load after the page due to the Geotargeting (Javascript doesn't have the Geo data until then). One possible solution would be to have Javascript jump back to the section after the banner loads, but this might be even more annoying since it would cause the page to jump twice instead of once. Thoughts?
Does PHP have the geotargetting info? If so, the height of the banner is known and can be written into the html whenever the country has only one banner (as in Australia)
No, PHP doesn't know the Geo info, nor does anything on the server side. At the end of a normal page request you'll see a call to <script type="text/javascript" src="http://geoiplookup.wikimedia.org/"></script>. This sets the Geo info in a global Javascript variable. That info is then used to choose which banner to display. We tried having the Geo call at the top of the page, but it caused the page loading to stall sometimes (if the Geo request took more than a second or so to return). We could theoretically have PHP do the Geo lookup and output the result to the page, but this would break the page caching and cause the servers to melt. It something of a chicken and egg problem. Any other ideas?
Aren't the banners the same size regardless of the geoip (or anything else?) We could just have a blank placeholder there until it loads.
Personally i think the jump back would be less annoying (if done right). (OTOH I'm personally not overly bothered by this whatsoever).
That's an interesting idea. I know that they used different sizes earlier in the fundraiser, but it does seem like they've started using a standard size recently. I'll ask them if they plan on sticking with that size or not.
The solution in r99341 was reverted for a couple reasons. Primarily, it slows down loading of the page itself, but also, we aren't sure how the wider community will respond to storing cookies for every user.
A full analysis of all the possible solutions to this bug can be found at:
http://wikitech.wikimedia.org/view/CentralNotice/Optimizing_banner_loading
There are many ways to cause this effect and we have not heard of this happening recently. I'm declining this bug. If we see this again, I would prefer a fresh bug with recent testing evidence.
I'm reopening this again. There are several duplicates of this task and many are old and the resolution is not straightforward. We will try to do a cleanup round, give context and link them all.
Thanks for looking into it. Is https://wikitech.wikimedia.org/wiki/CentralNotice/Optimizing_banner_loading still the most up to date "plan" on how to address the issue?
This is more-or-less the same as T52865: CentralNotice shifts down page content on load (causes mis-clicks), except the specific issue with anchors shouldn't be an issue on most browsers today (T52865#3411980).