[1.22.0] Image Upload becomes broken HTML tag in Chrome and Edge, but working Markdown in Firefox

[FrostKiwi]

Description

Regression after update from 1.21.5 to 1.22.0.
When uploading images via copy paste as a screenshot, the feature is now broken, depending on Browser, see Screenshots below.

On Firefox, when Pasting images, the behavior is the same as 1.21.5: Image gets pasted as Markdown and is visible. No broken links.

But on Microsoft Edge, the Links become HTML, not markdown and have broken links, as they they have the slash prefix, which are broken in a subpath context.
(Note: The file upload itself completes, you can fix this by changing it manually to Markdown)

Context: This is a Gitea instance on a subpath (domain.com/git)

[server]
SSH_DOMAIN = domain.net/git
DOMAIN = domain.net/git
HTTP_PORT = 3000
ROOT_URL = https://domain.net/git/

There have been multiple issues with subpaths around Gitea from time to time with broken file links appearing in different places, most recent: #31546

Gitea Version

1.22.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Note: (Arc-green theme used, but it is actually 1.22.0)

Edge (and Chrome)

Firefox

Git Version

No response

Operating System

No response

How are you running Gitea?

Installed via Binary

Database

None

[phrl42]

can also confirm that when an issue like this is created, webhooks are not being sent because:
{"ok":false,"error_code":400, "description":"Bad Request: can't parse entities: Unsupported start tag \"img\" at byte offset 270" }

this only happens on windows, when copy pasting images in with linux ( tested on manjaro 24.0.2 ), no issues resolve.

[silverwind]

The missing subpath in <img> URL sounds like a definite bug. It is intentional that this is <img> because you are pasting a HiDPI image and those need to be downscaled for display which is only possible with a <img> tag.

can also confirm that when an issue like this is created, webhooks are not being sent because: {"ok":false,"error_code":400, "description":"Bad Request: can't parse entities: Unsupported start tag \"img\" at byte offset 270" }

this only happens on windows, when copy pasting images in with linux ( tested on manjaro 24.0.2 ), no issues resolve.

This sounds a different bug in Markdown validation I think. Suggesting to open a separate bug report.

[FrostKiwi]

The missing subpath in <img> URL sounds like a definite bug.

Huh! That confuses me because the markdown, does not have the subpath, never had in past version and still works. There is some conversion happening not visible to the user I guess?
So the link for the image tag and markdown tag cannot be the same. This issue is more complex than I thought.

It is intentional that this is <img> because you are pasting a HiDPI image and those need to be downscaled for display which is only possible with a <img> tag.

Then we have a bug in Firefox, because there is a conversion on Chrome and Edge but not on Firefox.

[silverwind]

Ah it could be that we actually should not add the subpath into the markup but instead dynamically append it in backend while rendering. That will allow the backend to later change the subpath at will without breaking the images.

Essentially, subpath in <img> tags must render the same as ![]() style images.

[wxiaoguang]

You are using sub-path, it has been fixed in 1.22.1

Make pasted "img" tag has the same behavior as markdown image (#31235) #31243

[silverwind]

Then we have a bug in Firefox, because there is a conversion on Chrome and Edge but not on Firefox.

The mechanism is that if the PNG contains HiDPI metadata the image will render as <img> and this behaviour matches GitHub as well. So likely Firefox is stripping the image metadata for some reason, I would say it should not and that it's a browser bug. I do not observe this problem in Firefox on Mac, so maybe it's a browser bug that only manifests on Windows.

[wxiaoguang]

Related issue is this: Markdown image paste regressions #31230

[silverwind]

Yeah thas was it. So upgrade to 1.22.1 please. As for #31553 (comment) issue, please file a new issue with steps if still present.