Images uploaded via certain methods cannot be displayed in the timeline.

[YamatoRyou]

Steps to reproduce

1. Use the following code to upload an image:

#! /bin/bash
# Upload an image to Synapse and get the MXC URI of the image
mxc_uri=`curl --data-binary @$real_image_path "$server_url/_matrix/media/v3/upload?filename=image.png" \
-X "POST" \
-H "Authorization: Bearer $access_token" \
-H "Content-Type: image/png" \
--compressed`

# Send an event to a specified room as a specific account
timestamp=`date +%s`
result=`curl "$server_url/_matrix/client/v3/rooms/$room_id/send/m.room.message/$timestamp" \
-X "PUT" \
-H "Authorization: Bearer $access_token" \
-H "accept: application/json" \
-H "content-type: application/json" \
--data-raw "{\"info\":{\"mimetype\":\"image/png\",\"w\":$image_width,\"h\":$image_height},\"msgtype\":\"m.image\",\"body\":\"image.png\",\"url\":\"$mxc_uri\"}" \
--compressed`

2. Observe the timeline changes.

Outcome

What did you expect?

n/a

What happened instead?

As of 1.11.84, images uploaded by the above method can be displayed normally in the timeline.
As shown in the figure, since 1.11.86, images uploaded by the above method cannot be displayed in the timeline and can only be downloaded as files. However, images with the above characteristics can be displayed normally in applications on Android (including Element X) or iOS platforms.

The room is unencrypted.
In 1.11.86, Image files from the clipboard or user selection can still be displayed after being successfully sent.
This issue occurs in both the desktop and web client.

Operating system

x64 Windows 11 (10.0.22631)

Application version

Element Desktop 1.11.86

How did you install the app?

https://packages.element.io/desktop/update/win32/x64/index.html

Homeserver

Synapse 1.120.0

Will you send logs?

No

[t3chguy]

Your repro script isn't working for me, I get a HTTP/2 400

#!/bin/bash

server_url="https://matrix-client.matrix.org"
access_token="$TOKEN"
room_id="!vEbvlLWcuOoBBolcLL:matrix.org"

real_image_path="/Users/t3chguy/Downloads/element.png"
image_width=512
image_height=512

# Upload an image to Synapse and get the MXC URI of the image
mxc_uri=`curl -v --data-binary @$real_image_path "$server_url/_matrix/media/v3/upload?filename=image.png" \
-X "POST" \
-H "Authorization: Bearer $access_token" \
-H "Content-Type: image/png" \
--compressed`

# Send an event to a specified room as a specific account
timestamp=`date +%s`
result=`curl -v "$server_url/_matrix/client/v3/rooms/$room_id/send/m.room.message/$timestamp" \
-X "PUT" \
-H "Authorization: Bearer $access_token" \
-H "accept: application/json" \
-H "content-type: application/json" \
--data-raw "{\"info\":{\"mimetype\":\"image/png\",\"w\":$image_width,\"h\":$image_height},\"msgtype\":\"m.image\",\"body\":\"image.png\",\"url\":\"$mxc_uri\"}" \
--compressed`

Your repro example is passing {"content_uri":"mxc://matrix.org/YHMYhcTyAwzZkVlwcrHPqHbJ"} as url to the 2nd curl call.

I added | jq -r '.content_uri' to the end of the first curl call and then it worked as expected.

[YamatoRyou]

Your repro script isn't working for me, I get a HTTP/2 400

#!/bin/bash

server_url="https://matrix-client.matrix.org"
access_token="$TOKEN"
room_id="!vEbvlLWcuOoBBolcLL:matrix.org"

real_image_path="/Users/t3chguy/Downloads/element.png"
image_width=512
image_height=512

# Upload an image to Synapse and get the MXC URI of the image
mxc_uri=`curl -v --data-binary @$real_image_path "$server_url/_matrix/media/v3/upload?filename=image.png" \
-X "POST" \
-H "Authorization: Bearer $access_token" \
-H "Content-Type: image/png" \
--compressed`

# Send an event to a specified room as a specific account
timestamp=`date +%s`
result=`curl -v "$server_url/_matrix/client/v3/rooms/$room_id/send/m.room.message/$timestamp" \
-X "PUT" \
-H "Authorization: Bearer $access_token" \
-H "accept: application/json" \
-H "content-type: application/json" \
--data-raw "{\"info\":{\"mimetype\":\"image/png\",\"w\":$image_width,\"h\":$image_height},\"msgtype\":\"m.image\",\"body\":\"image.png\",\"url\":\"$mxc_uri\"}" \
--compressed`

Your repro example is passing {"content_uri":"mxc://matrix.org/YHMYhcTyAwzZkVlwcrHPqHbJ"} as url to the 2nd curl call.

I added | jq -r '.content_uri' to the end of the first curl call and then it worked as expected.

The code at that time was only the most important parts, and was not verified. Here is the reworked and verified code:

#! /bin/bash
cd "$(dirname $0)"

server_url="<synapse url>" # Due to my needs, the URL here points to Synapse itself instead of the reverse proxy in front of it
access_token="<your access token>"
room_id="<target room id>"
real_image_path="<image file path>" # The image file needs to be located in the same path as this script
image_width="<image width (px)>"
image_height="<image height (px)>"

# Upload an image to Synapse and get the MXC URI of the image
result=`curl -v --data-binary @$real_image_path "$server_url/_matrix/media/v3/upload?filename=image.png" \
  -X "POST" \
  -H "Authorization: Bearer $access_token" \
  -H "Content-Type: image/png" \
  --compressed`

# Get URI from previous variable
mxc_uri=`echo $result | jq -r ."content_uri"`

# Send an event to a specified room as a specific account
timestamp=`date +%s`
result=`curl -v "$server_url/_matrix/client/v3/rooms/$room_id/send/m.room.message/$timestamp" \
  -X "PUT" \
  -H "Authorization: Bearer $access_token" \
  -H "accept: application/json" \
  -H "content-type: application/json" \
  --data-raw "{\"info\":{\"mimetype\":\"image/png\",\"w\":$image_width,\"h\":$image_height},\"msgtype\":\"m.image\",\"body\":\"test\",\"url\":\"$mxc_uri\"}" \
  --compressed`

---

The response information of the above two curl executions are:

< HTTP/1.1 200 OK
< Server: Synapse/1.120.0
< Date: ***
< Content-Type: application/json
< Cache-Control: no-cache, no-store, must-revalidate
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, OPTIONS
< Access-Control-Allow-Headers: X-Requested-With, Content-Type, Authorization, Date
< Access-Control-Expose-Headers: Synapse-Trace-Id, Server
< Transfer-Encoding: chunked
<
{ [82 bytes data]

< HTTP/1.1 200 OK
< Server: Synapse/1.120.0
< Date: ***
< Content-Type: application/json
< Cache-Control: no-cache, no-store, must-revalidate
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, OPTIONS
< Access-Control-Allow-Headers: X-Requested-With, Content-Type, Authorization, Date
< Access-Control-Expose-Headers: Synapse-Trace-Id, Server
< Transfer-Encoding: chunked
<
{ [70 bytes data]

---

The above code can still reproduce the problem as of now. Test environment:
Element Desktop 1.11.86
Synapse 1.120.0 (running in Synology DiskStation Manager 6.2.3, Linux 3.10.105 as a Docker container)
The script uses UTF-8 encoding, Unix line break encoding, and bash as the shell.

---

The test script uses a newly created unencrypted room and the token of another account, and the result is the same.
As shown in the figure, the location where the image should be displayed is still displayed as an attachment.

I have currently found an alternative method to temporarily solve this problem.

[t3chguy]

Your issue in your 2nd script is the filename is test which does not pass the strict mime type checks added in https://github.com/element-hq/element-web/releases/tag/v1.11.85 - test could be an executable file hiding behind a thumbnail. You should use the filename field as per the spec to state the name of the file, then your body can be "test" if you so wish.

[YamatoRyou]

Your issue in your 2nd script is the filename is test which does not pass the strict mime type checks added in https://github.com/element-hq/element-web/releases/tag/v1.11.85 - test could be an executable file hiding behind a thumbnail. You should use the filename field as per the spec to state the name of the file, then your body can be "test" if you so wish.

I just replaced the file name pointed to by the script with the string I am an image, I also changed the actual file name of the image. However, the result is still the same. Or maybe a highly random string?

[t3chguy]

"I am an image" doesn't have a file extension which satisfies the image/png mimetype though. The body or filename field in the m.room.message event of msgtype m.image is what matters, not the filename you tell the media repository as that won't be shown in the event anywhere.

[t3chguy]

I suggest looking at the spec again https://spec.matrix.org/v1.12/client-server-api/#mimage

You are saying the name of the file is test or I am an image which doesn't satisfy strict mime type checks. Following the example in the spec, you can specify the filename in the body field or the filename field.

Closing as not an Element issue. The reason for mobile Element clients still showing your image is they do not do the strict mime type checking, though I believe they will in the future for additional security.

[YamatoRyou]

"I am an image" doesn't have a file extension which satisfies the image/png mimetype though. The body or filename field in the m.room.message event of msgtype m.image is what matters, not the filename you tell the media repository as that won't be shown in the event anywhere.

So that's what happened. I thought that body was a place to add comments to the image and was not related to the file name. I just added .png here, and the problem was solved.

[t3chguy]

I thought that body was a place to add comments to the image and was not related to the file name.

Only if you specify the filename via the filename field, otherwise it is the filename, as stated in the spec.

[YamatoRyou]

I thought that body was a place to add comments to the image and was not related to the file name.

Only if you specify the filename via the filename field, otherwise it is the filename, as stated in the spec.

Thanks.