Issue described in https://github.com/vector-im/riot-web/issues/9690.
With certain `window.devicePixelRatio` values
(e.g. `1.5789473684210527`), the calculated thumb width/height
would be a non-integer value.
Passing such values to `client.mxcUrlToHttp()` causes it to
generate URLs to the thumbnail API with non-integer values.
As per the spec, non-integer values are forbidden for that API and a
400 HTTP response is returned (`Query parameter b'width' must be an
integer`).
Fixing matrix-js-sdk's `mxcUrlToHttp()` to sanitize such values
would also be a good idea and likely fix more than just matrix-react-sdk
and riot-web. Still, it feels like matrix-react-sdk should play nice
as well, and not request thumbnails for weird widths/heights.
Signed-off-by: Slavi Pantaleev <slavi@devture.com>
When displaying a GIF, we always want to thumbnail so that we can properly
respect the user's GIF autoplay setting (which relies on thumbnailing to produce
the static preview image).
Fixes https://github.com/vector-im/riot-web/issues/9658
This allows Webpack to insert the proper image URL after builds steps like
adding a hash and so on. The path you supply to `require` is relative to the JS
source file, just like any other would be.
needs server to support 1600x1200 thumbnails for retina large ones.
ideally need to cap maximum thumbnail size to 800x600 rather than expand to arbitrary widths.
need to check that luke's funky timeline code doesn't get confused between naturalWidth and infoWidth etc.
also need to consider whether to encode a resolution metric in the event rather than lying about resolution.
Prior to #1912, height fix up of image events without an `info` in their
content would fail, setting `style.height = null + "px"`.
Now that all thumbnail sizing is done through one path, we can fix the
same problem for all cases (images, stickers, e2e/non-e2e) by handling
images without `info` correctly.
At the bare minimum, we use a null-guard that will make sure an image
without an `info` does not appear in the timeline (as a spinner or
otherwise until loaded). When loaded, we size it like any other image
by using the natural dimensions of the loaded image in place of `info`.
Note that we do not apply the same logic to images that *do* specify an
`info` with `w` and `h` keys. If the aspect ratio of the image does not
match that of the event, we use the one in `info` even when the image
has loaded.
The benefits of this:
- One code path for determining spinner/placeholder and it's position
for loading images/stickers. This includes spinner used in e2e
decryption of images.
- Very small definition for MStickerBody, only overriding the minimal
differences is has from MImageBody.
The disadvantages:
- Slightly more complicated MImageBody, but hopefully not less
readable.
As the slightly nicer alternative to fixupHeight being applied once
we actually have a timelineWidth.
The niceness comes from not needing timelineWidth, which means we can
implement at render time with CSS. (Despite still calculating aspect
ratios when we render.)
Michael Telatynski