"Contain" images with missing dimensions instead of cropping them

[gaearon]

Addresses #6800

As noted in #6474, we don't want to use dynamically fetched dimensions on the client because it causes layout shifts for any post(s) after the image. In the worst case this can cause an entire cascade of relayouts which is absolutely terrible for performance.

However, as discussed in #6800, cropping can feel pretty disruptive. Instead, let's try "containing" when the aspect ratio is unknown.

This only affects images with missing dimensions. (Currently, it's up to the client to specify the dimensions.) In longer term it would be nice if the server could somehow fill out the missing ones, but fixing that is out of scope of this PR.

I had to disable the lightbox animation for such images because the initial sizing is going to be different in the "contains" layout. While disabling the animation, I noticed flashes on first and last frames, which the two last commits take care of.

Test Plan

Find an account with images that are missing dimensions, for example https://bsky.app/profile/wrtrstat.bsky.social

Verify that images with unknown aspect ratio are now "contained" instead of cropped.

Verify that opening them in the lightbox works, but skips the expanding animation.

Verify that opening images with dimensions remains fluid and animated.

Test all platforms.

Before

After

[github-actions]

Old size	New size	Diff
8.14 MB	8.14 MB	0 B (0.00%)

---

[haileyok]

Tested web and Android, works well.

[WriterStat]

Hi, I like you all.

It works better than the previous system breaking fix, but it is not a good fix long term for lack of mandatory field communication. Temp fix at best. The changes from the last update need to be rolled back to the prior original working code before the breaking changes were made for now instead. And mandatory fields need to be communicated to your 3rd party and client post submission ecosystem, even if only in rule, then the code itself will basically age out fast, will no longer be used for any new posts. Problem goes away by itself.

Change instead needs to happen on image upload api/fields required for your client post submission ecosystem.

See the new posts on #6800

The previous breaking change made before this one made my page on Bluesky basically unusable, I wasn't the only one, with 20 million. This one will allow it to be read, but will make Bluesky less visually usable/likeable, a longer process to read/see and longer pages to interact with and you will be stuck with it. Make the change in image submission/image upload instead to fill the mandatory fields needed to work. That fixes your original problem.

Or get/calculate the data needed and store it on the first image request call, so it doesn't need to run the hack code more than one time. Also fixes your original problem.

[ChrisArchitect]

Rolling this back yet? Going to squares with css contain breaking a long held standard for opengraph preview image dimensions to fix 'layout shift' or whatever is not a good look. And it not being emphasized in the API docs/examples about the aspectratio parameter means many many things have been thrown out of wack.