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 over-simplifications!)
---------
1. Basic page links, with Banner notices (Central/Site/Geo/Watchlist): Example: Everyone in Venezuela should be seeing this WLM banner currently: https://meta.wikimedia.org/w/index.php?title=Main_Page&banner=wlm_2017_v... 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 links. 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): https://meta.wikimedia.org/w/index.php?title=Wikimedia_News&banner=wlm_2... Problem: These push *down* the "page content", *in some browsers*
2b) Example - collapsed sections/tables above the link-target: https://en.wikipedia.org/wiki/Ant#Relationship_with_humans 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.
Details: 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: https://bugzilla.mozilla.org/show_bug.cgi?id=43114
-----------
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 proposal) Solution 2: [code-change] - I think there might be further JavaScript/ResourceLoader tweaks that could be done here, but I'm not sure.
------------
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 discussions. 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 jmh649@gmail.com 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
https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Button_load_issues
J
On Sun, Sep 3, 2017 at 11:01 AM, David Gerard dgerard@gmail.com wrote:
On 2 September 2017 at 02:09, Michael Peel email@mikepeel.net 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: https://meta.wikimedia.org/ wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/ wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- James Heilman MD, CCFP-EM, Wikipedian
The Wikipedia Open Textbook of Medicine _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe