[Summary] Improve issue/PR comment editing experience

[wxiaoguang]

There are many issues about the issue editing problems. Including:

• The EasyMDE/CodeMirror is not as fluent as a native textarea.
• Mobile experience (especially for Android by EasyMDE/CodeMirror).
• Failed request causes content lost (CSRF token expires after 24h, account switch, network problem).
• Page load would lead to content lost (Close browser, improper in-page reload, etc).
• Old content would be overwritten without any feedback when editing existing comments.
• The attachments (drop-in upload, pasting upload) are difficult to manage, code was messy.

Proposal:

• Replace the EasyMDE/CodeMirror with a native textarea editor like GitHub
  • The EasyMDE doesn't improve user experience too much, it's not a real wysiwyg editor.
  • If there is no objection from most users and big communities (ps: @brechtvl @drsybren I guess you are using Gitea for Blender, could you help to confirm do your users prefer EasyMDE or native textarea like GitHub?)
• Always use AJAX to submit comments
  • Then there is a chance to show errors/feedbacks to users if anything wrong happens or the old content had been
    changed before this edit.
  • The first step Change form actions to fetch for submit review box #25219
  • Use fetch to send requests to create issues/comments #25258
• Use LocalStorage to save drafts
  • No server-side storage because many people care about "privacy", they do not want to send drafts to server.
  • The details are complex, and there is no perfect solution yet. So we can just do our best to avoid losing contents, and maybe it's fine to leave some "already submitted contents" in draft for a short time (rare case)
• Refactor the legacy dropzone code and uploading code.

(there are a lot of related issues, I may link them here later)

[a1012112796]

related #15070 .

[brechtvl]

If there is no objection from most users and big communities (ps: @brechtvl @drsybren I guess you are using Gitea for Blender, could you help to confirm do your users prefer EasyMDE or native textarea like GitHub?)

From the feedback I've seen, a native textarea is preferred.

Use LocalStorage to save drafts

Lost comments (or description edits, file edits) is one of the more important things to improve for us, so any solution here would be very welcome. LocalStorage would improve the situation a lot I think.

We used Phabricator before which would save drafts server side, and developers really liked that. You could start writing on one computer and then continue later on another. For example a desktop at work, laptop at home, phone during a commute, tablet, different operating system, etc. So maybe that approached could be considered too.

Always use AJAX to submit comments

In general would be nice for any issue edits to not reload the page, including labels, projects, reviewers, etc. Some of this is already using AJAX but I guess it has to reload the page to confirm the edit completed successfully and update the timeline. Personally I could live without a timeline update.

Refactor the legacy dropzone code and uploading code.

Ability to drag & drop images and video directly into the textarea would be very welcome.

[silverwind]

Regarding storage of unsaved comments, it could use a simple key/value system where URL is the key and value are the data like title/body etc. For new issues/prs, it can be keyed on the "new" URL, for PR comments, I think it could use the "thread" id. So this will at most store one comment by URL, which is sufficient.

Server-side storage might be nice, but needs some thoughts regarding "garbage collection", e.g. whether there should be age and size limits on how long to retain unsaved data as it will otherwise accumulate endlessly on the server.

[silverwind]

I recommend to start with the EasyMDE removal first before attempting other changes as that code would otherwise have to be thrown away most likely because EasyMDEs interface is so different from a textarea.

[delvh]

URL is the key is not sufficient, there might be more than one unsaved comment per page.
We should in this case use something like the element ID as well.
Apart from that, I absolutely agree with both comments.

[wxiaoguang]

Server-side storage might be nice

There will be a lot of people who care about "privacy" having strong objection about the server-side storage.

Update: I added this to the issue's description.

start with the EasyMDE removal first

That's why the Replace the EasyMDE/CodeMirror comes first. And luckily, I have been working on an abstract interface for different editors (see the TextareaEditor , CodeMirrorEditor classes)

[silverwind]

URL is the key is not sufficient, there might be more than one unsaved comment per page.

URL key only for the main comment box. Sub-Threads like PR comments have their thread id in the URL hash to allow multiples, e.g. URL with path and hash as key is sufficient. URL origin, I would remove from the key so multi-domain scenarios work.

[drsybren]

• Replace the EasyMDE/CodeMirror with a native textarea editor like GitHub

  • The EasyMDE doesn't improve user experience too much, it's not a real wysiwyg editor.
  • If there is no objection from most users and big communities (ps: @brechtvl @drsybren I guess you are using Gitea for Blender, could you help to confirm do your users prefer EasyMDE or native textarea like GitHub?)

👍 from me. Native text boxes work well, and I'm constantly struggling with the current editor (like the Home key not taking line wrapping into account).

I do feel that would be nice if this were paired with a consistent 'MarkDown input means preview is available' approach. For example new PRs cannot be previewed.

• Always use AJAX to submit comments

I don't know how currently updates from the back-end are sent to the front-end. If XHR/AJAX is used to submit changes, then it's good to have a way to asynchronously receive changes as well. For Flamenco (which is also a Go backend and a web frontend) I've used SocketIO for this, together with this approach:

• Any action performed by the front-end is sent to the back-end via the OpenAPI (Swagger v3) JS client.
• The API response only indicates success or various failures, but doesn't trigger any re-display of anything.
• Changes to the data are sent via SocketIO, and only those trigger changes to the display.

This makes it very simple to have an always-up-to-date user interface, as it doesn't matter whether a change was done by the current user or by somebody else -- every change is sent via one channel: the SocketIO connection.

• No server-side storage because many people care about "privacy", they do not want to send drafts to server.

This I don't find terribly convincing. If those people are typing things with the intent to submit to Gitea anyway, it's not that much a matter of privacy, and more about predictability of the system. It makes total sense to be explicit about sending whatever is typed/pasted into input fields to the server. Having clarity and control over this IMO is key here.

As Brecht also said, this feature is something Blender developers are used to, and have been happily using for years. It's something I'm missing too. Priority is to not loose any edits, though.

• The details are complex, and there is no perfect solution yet. So we can just do our best to avoid losing contents, and maybe it's fine to leave some "already submitted contents" in draft for a short time (rare case)

Local storage is cheap, so having some data linger on my own computer for a while longer is absolutely fine.

As an extra thought, it would be great if some input fields could map to the same draft storage. This would make the PR review process a lot nicer for us. PR reviews often start with a discussion on the design of the approach; looking at the code comes later. This means that I'd have to open two tabs: one with the patch description (that contains the design description) and one with the code changes (that contains the comment box with the approve/reject buttons). It would be so much better if:

• PRs could be approved/rejected from the discussion page, and/or
• a comment typed on the discussion page would transfer to the code changes page and vice versa.

[wxiaoguang]

@drsybren Thank you very much.

asynchronously receive changes ... SocketIO

That's really a good idea, and it would bring much more other benefits, the only problem is it's more complicated, even as GitHub, sometimes I still need to refresh the page to see some latest changes. So I think we can consider it after this proposal.

server-side ... privacy

The problem is, I know some people worry about they might (by mistake) paste "password" or "secret" into the textarea, if the draft is stored on server-side, then these secrets would leak 😆 So I think at the moment LocalStorage is a generally acceptable solution. Maybe in the future we could make this feature as general as possible, then there would be a plug-able server-side storage for some deployments?

a comment typed on the discussion page would transfer to the code changes page and vice versa.

I will try to figure it out, but I haven't got a clear picture about all details.

---

I think I would start the work after Gitea 1.19.0 or 1.19.1 releases, to prevent from making bug-fix backports difficult.

[drsybren]

The problem is, I know some people worry about they might (by mistake) paste "password" or "secret" into the textarea, if the draft is stored on server-side, then these secrets would leak

Yeah, as I said, I don't find it a particularly strong argument. People who copy-paste secrets into a submission form that shouldn't receive those secrets are already doing something dubious. You have to balance that with the added comfort for anyone else who works on more than one computer.

The final call is yours, of course, and I agree that a Local Storage based approach is a good start anyway.

[silverwind]

Socket.IO

I would not recommend pointless WebSocket wrappers like that, they are just baggage. Sending/Receiving JSON and automatically reconnecting a Websocket can be done in a few lines of code. Each dependency adds maintenance burden and brings future security issues, better do such things without dependencies.

That said, I don't see a compelling use case for commenting to use WebSocket. If it needs changes at all, I would make it purely client-to-server REST or just keep the existing HTML form API.

[drsybren]

I would not recommend pointless WebSocket wrappers like that, they are just baggage.

This is a bit harsh. SocketIO has features that I personally found very well suited for my use case:

• Automatic reconnects with exponential backoff.
• 'Chatroom-like' channels that can be joined and left by the client, which can be used to control which client(s) receive information on which topic.
• Ability to register callbacks depending on the received message type.

Frankly that was enough for me to not bother implementing this myself.

That said, I don't see a compelling use case for commenting to use WebSocket. If it needs changes at all, I would make it purely client-to-server REST or just keep the existing HTML form API.

I only used (and intended to suggest) SocketIO for server-to-client communication. In the Flamenco architecture the client sends data to the back-end via its OpenAPI REST API. SocketIO is only used to update the view of the web client when things change on the server (regardless of who triggered that change).

What you implement in Gitea is of course 100% your choice. I just wanted to offer some inspiration.

[wxiaoguang]

I see all your points, I am open to either solution as long as it's clear and functional. It's too early to make a decision for the framework and it's (somewhat) off-topic. I think we can postpone the framework choosing topic to the future when we have time for it?