There are 4 or more different problems being discussed here, and it
would be helpful to be precise about each of them, and keep them
separate because they are technically distinct, despite being
thematically linked. (Note: I'm not a dev, which both helps me
simplify the explanation, but also means there might be errors or


1. Basic page links, with Banner notices (Central/Site/Geo/Watchlist):
Example: Everyone in Venezuela should be seeing this WLM banner currently:
Problem: These push down the "page content", by the height of the
banner. The desired page content is usually still visible, but it is
still annoying whether reading or trying to click on page content
Cause 1: The geo-targetting javascript takes time to complete. The
only way we could prevent this, is to delay the visibility of the
entire page, for everyone in the world, whilst the code checks whether
or not the reader is in the defined geographic region.
Cause 2: The other javascript takes time to complete. Same as 1, but
for non-geo-targeted notices. (E.g. notices only shown to logged-in
editors with more than 1000 edits.) This is faster, but still takes
time, and per Krinkle's explanation above it is not done until the
page contents are displayed.


2. #subsection-links with page bump issues:

2a) Example - banners (as above):
Problem: These push *down* the "page content", *in some browsers*

2b) Example - collapsed sections/tables above the link-target:
Problem: These push *up* the "page content", *in some browsers*.
Sometimes they push it up a *lot*. This means it is above the visible
area, which is both annoying and confusing.

In Chrome/Chromium these links work fine, even if you have fancy
gadgets like "Improved appearance for mobile, narrow and wide screens"
enabled, because Chrome/Chromium uses "scroll-anchoring".
In Firefox, these links get the "page bump" problem. Firefox's
upstream bug:


3. Gadgets and features that are added to the site's User Interface
(userlinks (personal bar), pagelinks (vector's tab bar), sitelinks
(sidebar), etc):
Example: In the Vector skin, the gadget Twinkle adds its "TW"
dropdown-menu tab to the right (in LTR languages) of the
"vector-more-actions" dropdown-menu tab, but it doesn't appear until a
few seconds after the rest of the page loads.
Cause: Per Krinkle's explanation, the JavaScript is done after the
page content has finished loading.
Solution 1: [layout-change] - We could simply move the "TW"
dropdown-menu tab so that it appears in a slightly less-logical place,
i.e. to the left (in LTR languages) of the "Read" tab. (per Doc James
Solution 2: [code-change] - I think there might be further
JavaScript/ResourceLoader tweaks that could be done here, but I'm not


4. Gadgets and features that change the wikitext editing textarea:
Example: In the 2010 wikitext editor, if the "Advanced" or "Special
characters" or "Help" sections were expanded in the previous editing
session, then they will be expanded in your next editing session.
However but they won't "open" until after everything else has loaded.
Cause: ? (I haven't stumbled across the details on this one, yet.)


TLDR: These are all old problems.
Lumping them all together (as this thread is doing, and as quite a few
phabricator tasks do, e.g. T138177) leads to confusing/frustrating
Over the years, the possible solutions change for each of these
issues, due to external browser evolution and internal
code-infrastructure evolution - but solving it for older browsers
makes everything complicated (i.e. Firefox could fix their bug today,
but it would only help users who updated their browser), and IIUC
supporting older gadgets/extensions also makes everything complicated
(i.e. we try not to create "breaking changes").
These issues annoy everyone. If they were easy to fix, they would've
been fixed. The developers regularly discuss the issues, and improve
what they can.

On Sun, Sep 3, 2017 at 10:44 AM, James Heilman <> wrote:
> These issues can be fixed. Have the banners load below the buttons we
> typically click on. Move the gadgets to the left of "read" rather than to
> the right of "view history". I have proposed this for TW as I mentioned here
> J
> On Sun, Sep 3, 2017 at 11:01 AM, David Gerard <> wrote:
>> On 2 September 2017 at 02:09, Michael Peel <> wrote:
>> > This is possibly the most annoying feature of the Wikimedia projects at
>> the moment. You access a page. Then you start reading or editing it. And
>> then suddenly the page jumps when a fundraising banner / central notice /
>> gadget / beta feature loads. So you have to start reading the page again,
>> or you have to find where you were editing again, or you have to undo the
>> change you just made since you made it in the wrong part of the page.
>> Or you click "edit" and it hits the banner that suddenly popped up
>> under your click. AAAAAAAAAAAA
>> - d.
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> wiki/Mailing_lists/Guidelines and
>> wiki/Wikimedia-l
>> New messages to:
>> Unsubscribe:,
>> <>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
> The Wikipedia Open Textbook of Medicine
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> and 
> New messages to:
> Unsubscribe:, 
> <>

Nick Wilson (Quiddity)
Community Liaison, Wikimedia Foundation

Wikimedia-l mailing list, guidelines at: and
New messages to:

Reply via email to