github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 10:35:44 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-02 10:35:44 -06:00
Owner
Copy Link

Originally created by @FrostKiwi on GitHub (Jul 4, 2024).

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: https://github.com/go-gitea/gitea/issues/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)

image
image

Firefox

image
image

Git Version

No response

Operating System

No response

How are you running Gitea?

Installed via Binary

Database

None

Originally created by @FrostKiwi on GitHub (Jul 4, 2024). ### 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: https://github.com/go-gitea/gitea/issues/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) ![image](https://github.com/go-gitea/gitea/assets/60887273/c7836c9b-d85f-4bab-bae2-b1cb55f579fe) ![image](https://github.com/go-gitea/gitea/assets/60887273/31f9be6f-1d32-4572-b3f4-497e7c392ff9) ## Firefox ![image](https://github.com/go-gitea/gitea/assets/60887273/a98fac9e-3213-4e80-b6cd-d2838bc544e7) ![image](https://github.com/go-gitea/gitea/assets/60887273/0a49f44a-3de9-4e51-bc57-f1258ed63a84) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Installed via Binary ### Database None
GiteaMirror added the issue/needs-feedback label 2025-11-02 10:35:44 -06:00
GiteaMirror commented 2025-11-02 10:35:45 -06:00
Author
Owner
Copy Link

@phrl42 commented on GitHub (Jul 4, 2024):

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.

@phrl42 commented on GitHub (Jul 4, 2024): 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.
GiteaMirror commented 2025-11-02 10:35:45 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 4, 2024):

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.

@silverwind commented on GitHub (Jul 4, 2024): 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.
GiteaMirror commented 2025-11-02 10:35:45 -06:00
Author
Owner
Copy Link

@FrostKiwi commented on GitHub (Jul 4, 2024):

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.

@FrostKiwi commented on GitHub (Jul 4, 2024): > 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.
GiteaMirror commented 2025-11-02 10:35:45 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 4, 2024):

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.

@silverwind commented on GitHub (Jul 4, 2024): 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.
GiteaMirror commented 2025-11-02 10:35:46 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jul 4, 2024):

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

@wxiaoguang commented on GitHub (Jul 4, 2024): 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
GiteaMirror commented 2025-11-02 10:35:46 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 4, 2024):

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.

@silverwind commented on GitHub (Jul 4, 2024): > 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.
GiteaMirror commented 2025-11-02 10:35:46 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jul 4, 2024):

Related issue is this: Markdown image paste regressions #31230

@wxiaoguang commented on GitHub (Jul 4, 2024): Related issue is this: Markdown image paste regressions #31230
GiteaMirror commented 2025-11-02 10:35:46 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 4, 2024):

Yeah thas was it. So upgrade to 1.22.1 please. As for https://github.com/go-gitea/gitea/issues/31553#issuecomment-2208590947 issue, please file a new issue with steps if still present.

@silverwind commented on GitHub (Jul 4, 2024): Yeah thas was it. So upgrade to 1.22.1 please. As for https://github.com/go-gitea/gitea/issues/31553#issuecomment-2208590947 issue, please file a new issue with steps if still present.
GiteaMirror commented 2025-11-02 10:35:46 -06:00
Author
Owner
Copy Link

@FrostKiwi commented on GitHub (Jul 5, 2024):

Can confirm it being fixed with 1.22.1.

Interestingly, Markdown and HTML image tags have different paths though.
Inserting in Firefox, which inserts as Markdown, the screenshot becomes
![image](/attachments/23503808-f0bc-4d6e-bae4-d8eed57e632e)
With the slash in front. (This is technically wrong in the context of the subpath, but as mentioned by @silverwind in https://github.com/go-gitea/gitea/issues/31553#issuecomment-2208870991 it seems to be adjusted dynamically)

The new behavior of conversion to the HTML IMG tag does not add the slash in front:
<img width="483" alt="image" src="attachments/65a56fc3-1a85-41a0-97d2-470cf9d71de6">

@FrostKiwi commented on GitHub (Jul 5, 2024): Can confirm it being fixed with `1.22.1`. Interestingly, Markdown and HTML image tags have different paths though. Inserting in Firefox, which inserts as Markdown, the screenshot becomes `![image](/attachments/23503808-f0bc-4d6e-bae4-d8eed57e632e)` With the slash in front. (This is technically wrong in the context of the subpath, but as mentioned by @silverwind in https://github.com/go-gitea/gitea/issues/31553#issuecomment-2208870991 it seems to be adjusted dynamically) The new behavior of conversion to the HTML IMG tag does not add the slash in front: `<img width="483" alt="image" src="attachments/65a56fc3-1a85-41a0-97d2-470cf9d71de6">`
GiteaMirror commented 2025-11-02 10:35:47 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 5, 2024):

I agree we should be consistent with that slash and not having it would be better because paths that start with slash are meant to be "absolute" which these should not be.

@silverwind commented on GitHub (Jul 5, 2024): I agree we should be consistent with that slash and not having it would be better because paths that start with slash are meant to be "absolute" which these should not be.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/needs-feedback
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#13235
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?