-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix EOL handling in web editor #27141
Conversation
At least I can rule out golang from stripping the |
web_src/js/features/codeeditor.js
Outdated
@@ -105,14 +105,26 @@ export async function createMonaco(textarea, filename, editorOpts) { | |||
monaco.languages.register({id: 'vs.editor.nullLanguage'}); | |||
monaco.languages.setLanguageConfiguration('vs.editor.nullLanguage', {}); | |||
|
|||
// TODO: there must be a better way to preserve CRLF in the template rendering |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess there is no other way besides using JS.
HTML standard does play tricks with CRLF/LF for textarea value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a self-inflicted issue by gitea's HTML rendering. But no idea where the removal of \r
happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not related to Gitea.
For historical reasons, the element's value is normalized in three different ways for three different purposes.
The raw value is the value as it was originally set. It is not normalized.
The API value ... It is normalized so that line breaks use U+000A LINE FEED (LF) characters.
textarea.value
is the API value IIRC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also tried passing as data-value
and the \r
was stripped as well there. So it's not related to textarea.value
. It must be something in our HTML renderer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The standard has clarified that there is no CR but only LF when parsing HTML. I do not know how to explain more.
Nothing is unexpected, everything is right from HTML/Golang/GoTemplate/Gitea side.
The only wrong thing is that you shouldn't emit "\r" into HTML directly if you want to keep it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. I fail to see how that is related to the problem. I have shown that regular go template does not have the problem, but ours rendering does, so it's a bug in our rendering.
Your code is wrong. I have already shown that our code renders "\r\n" correctly: #27141 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you mean the browser discards it during HTML parsing stage? I will check with curl to confirm. If this is true, then yes, we need to encode it.
I'm also wondering which encoding would be best in terms of output size and parsing speed. Maybe JSON-encoding the string might be best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curl confirms, it's output correctly. Damn browsers and their silly parsers:
curl -s http://localhost:3500/devtest/gitea-ui | grep data-foo= | xxd
00000000: 3c64 6976 2063 6c61 7373 3d22 7061 6765 <div class="page
00000010: 2d63 6f6e 7465 6e74 2064 6576 7465 7374 -content devtest
00000020: 2075 6920 636f 6e74 6169 6e65 7222 2064 ui container" d
00000030: 6174 612d 666f 6f3d 2261 0d0a ata-foo="a..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with f394554.
It's ready now. Data is passed through JSON encoding from backend to frontend now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR description also needs to update.
Removed the WIP note in description. |
Fixes go-gitea#27136. This does the following for Monaco's EOL setting: 1. Use editorconfig setting if present 2. Use the file's dominant line ending as detected by monaco, which uses LF for empty file
Backport #27141 by @silverwind Fixes #27136. This does the following for Monaco's EOL setting: 1. Use editorconfig setting if present 2. Use the file's dominant line ending as detected by monaco, which uses LF for empty file Co-authored-by: silverwind <me@silverwind.io>
* giteaofficial/main: Add missing public user visibility in user details page (go-gitea#27246) Use mask-based fade-out effect for `.new-menu` (go-gitea#27181) [skip ci] Updated translations via Crowdin Fix z-index on markdown completion (go-gitea#27237) Update database-preparation and add note re: MariaDB (go-gitea#27232) cleanup locale function usage (go-gitea#27227) Fix EOL handling in web editor (go-gitea#27141) Fix PushEvent NullPointerException jenkinsci/github-plugin (go-gitea#27203) fix issues on action runners page (go-gitea#27226) Fix Fomantic UI dropdown icon bug when there is a search input in menu (go-gitea#27225) Update go-enry to 2.8.5 (go-gitea#27215) Update nodejs installation method in release container (go-gitea#27207) Quote table `release` in sql queries (go-gitea#27205) Fix push mirror, wrong timestamp format (go-gitea#27153) Allow copying issue comment link on archived repos and when not logged in (go-gitea#27193) fix: text decorator on issue sidebar menu label (go-gitea#27206) Update JS and Poetry dependencies and eslint (go-gitea#27200) Remove some dead code (go-gitea#27196) # Conflicts: # templates/repo/issue/view_content/context_menu.tmpl
The fixes have broken it. All my files are LF and when edit in browser, it always changes to Windows. This is very frustrating. Were the fixes regression--tested at all? I can't possibly be the only person editing files in a Windows browser. Both Firefox and Chrome are affected. |
If there is no quick fix, let's revert this PR. |
This reverts commit 3a187ea.
I have also encounter this problem. |
By the way, as you've noticed yourself now, it isn't quite easy to catch a Windows bug when most maintainers are using Linux/Mac… 😉 |
Yes I just encountered the bug where all LF got converted to CRLF, with v 1.21.0. The repository has no .gitattribute. |
You might want to try 1.21.0 nightly for the time being. I'm using nightly and the change was reverted there. I still can't understand the rationale behind using a user's OS to force CRLF EOL even when the editor correct detected non-Windows files. |
It's not related to OS, but it is a changed behavior caused by backend code for how to use HTML textarea content. |
Fixes #27136.
This does the following for Monaco's EOL setting: