There are multiple font-size changes when the page is loading. We load 'oojs-ui-widgets.styles' synchronously on Special:Preferences, and this appears to be the culprit, because if I remove 'oojs-ui-widgets.styles' from the 'oojs-ui-widgets' module, this FOUC goes away.
Description
Description
Details
Details
Event Timeline
Comment Actions
I can reproduce this in Chrome and Firefox, but only when I have developer tools open.
I don't know why this would happen. Perhaps we're just shipping too much CSS and we're hitting some limit where the browser decides to apply the CSS it has parsed so far before parsing the rest? I don't know what we could do here, besides shipping less CSS (e.g. just copy-pasting the parts we need to display the fake PHP tabs).
Comment Actions
It looks super funny because of .oo-ui-menuLayout > .oo-ui-menuLayout-menu, .oo-ui-menuLayout > .oo-ui-menuLayout-content { transition: all 200ms ease; } – so when the rule .mw-body-content { font-size: 0.875em; } is applied, the font size the entire preferences form animates from 1em to 0.875em. That's why it looks like it changes multiple times, but in reality I'm pretty sure it changes just once. And .mw-body-content { font-size: 0.875em; } loads late because it's part of the 'skins.vector.styles' module, which happens to be alphabetically the last one.
Comment Actions
@Ryasmeen This has been improved by @matmarex and made it into OOUI v0.27.2. Would you compare the task description with current implementation on https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:Preferences&ooui=1
Comment Actions
To be specific, the relevant patch was rGOJUb6b931e8dff4: MenuLayout: Avoid `transition: all`, be precise, I didn't tag it with this task because I didn't expect it to actually help much. But I don't see the annoying font-size changes anymore, so perhaps it did…
Comment Actions
I can't reproduce the original issue with older versions of the code now, either, so I think it must have been fixed by something unrelated.
Comment Actions
Change 444897 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] mw.special.preferences: Prevent invisible accessibility hint from affecting content
Comment Actions
The page still visibly shifts around twice while loading (this is after my patch above).
 | → |  | → |  |
That looks like several different issues. One of them is filed as T193731, I don't know what causes the others.
Comment Actions
Change 444897 merged by jenkins-bot:
[mediawiki/core@master] mw.special.preferences: Prevent invisible accessibility hint from affecting content
Comment Actions
Change 458852 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/core@master] Prevent field margin FOUC when loading OOUI special:preferences
Comment Actions
Change 458852 merged by jenkins-bot:
[mediawiki/core@master] Prevent field margin FOUC when loading OOUI Special:Preferences
Comment Actions
It looks like we accidentally worked around T193731 with commit f2a83fe4ac1c603b7f70d12566e5f8e9bcba1bcd. These fields are no longer auto-infused, so the bug where their spacing changes no longer affects us (at least on the initial load). So I guess this is fixed.
I still see a small problem with the ULS "More language settings" link, which seems to shift the page by 1px after it appears (it's worse in non-OOUI preferences). I submitted https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UniversalLanguageSelector/+/458892 for that. It's not really a blocker though.
Comment Actions
@Volker_E: I don't see the issue of vertical jump anymore. So that part is fixed. However, I am noticing now a horizontal movement of the content ever so slightly as I reload the page.
Here is a screen capture.
Comment Actions
@Ryasmeen @Jdforrester-WMF and myself narrowed the horizontal shift down to a Vector behaviour when scrollbars are appearing and has been the case before. With that we'll file a task and this can be set to “resolved” successfully.