While loading the viewer, images are replaced with a 'Loading thumbnail...' placeholder, which causes the page content to jump up, and then down again once the images loaded. This causes two unnecessary reflows.
- Mentioned In
- T204621: Reduce footprint of ext.3d on page initialisation
rETHRd7e35b697c01: Remove small height flicker with vertical-align rule
rETHRa6427348e6a4: Remove small height flicker with vertical-align rule
rETHR401b47b7f014: Remove small height flicker with vertical-align rule
rETHR112f1330f54e: Avoid height jump (FOUC) when showing 'loading' placeholder
rETHRe51d615772a9: Avoid height jump (FOUC) when showing 'loading' placeholder
rETHRe8b2fbbdaeb8: Avoid height jump (FOUC) when showing 'loading' placeholder
- Mentioned Here
- T183310: Preview image for 3D file fails to load shortly after upload
Hi @Esanders . We added this code because in many tests it simply took a while for the static images to generate. If the user went to the 3D file's brand new file page immediately after upload, it would take 15-20 seconds for the preview image to appear for the larger, more complex files (in some cases it even left a broken image on the page). We've taken a few steps to improve the user experience and communicate that sometimes there's processing still going on behind the scenes.
We'll continue to monitor real-world performance and adjust as necessary.
Thanks for the context. What appears if the image is still generating? Can't we just render the loading message above the image?
For files where the thumbnail has already been generated (which going forward will probably represent 99% of pageviews), we currently hide the image until the img.onload event fires, which seems unnecessary.
This is what appears while the image is still generating (the spinner is animated in the real version).
We could potentially put the Loading message above the image, but I think the reason we have the thumbnail as hidden is because of the aforementioned instances where there would be some kind of timeout and the image would appear as broken before it actually showed up and that was confusing (see T183310).
We're totally open to alternative solutions though.
Yeah - I meant how does the image tag appear if not hidden by your code. I think in this case there would probably be a fail event (image.onerror), which you could use to show another message.
It could be anything from being available immediately to taking a while to load/fail (generating/slow connection) to failing right away (rate limited, other issue).
It's not unlikely that a thumb is not immediately available right after upload, which is why we wanted to show a placeholder instead (T183310)
That said, we can probably optimize for the more common case where a thumb is readily available.
I'd suggest waiting a couple of ms or so before hiding the image (instead of doing it immediately as we do now) to prevent the quick FOUC if the image is immediately available.
I updated https://gerrit.wikimedia.org/r/410457 & added that delay - let me know what you think!
There is still a slight flicker when the <span class="mw-3d-wrapper"> is introduced, apparently having nested inline-block elements adds a few extra pixels of height, but it looks like we can fix that with a vertical-align rule: https://stackoverflow.com/questions/15936336/inline-block-element-nested-in-another-inline-block-element-has-an-offsettop