Skip to content
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

Zero-change edit is not zero-change #23669

Closed
tomsmeding opened this issue Nov 1, 2022 · 4 comments
Closed

Zero-change edit is not zero-change #23669

tomsmeding opened this issue Nov 1, 2022 · 4 comments
Labels
A-Composer A-Message-Editing O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect

Comments

@tomsmeding
Copy link

Steps to reproduce

  1. Send a message with two * embedded in one word, for example hi*hi*hi
  2. Edit that message by pressing arrow-up
  3. Observe that the * have changed to _ -- that's not what you entered before
  4. Submit the edit (you need to type something (not necessarily change something) to make Element accept the edit -- but this can be space + backspace)
  5. Observe that the message now says "hi_hi_hi" instead of "hihihi" which it was before

Outcome

What did you expect?

I expect that making no edits to a message (or to a part of a message) does not change that (part of the) message.

What happened instead?

It looks like Element reverse-engineers the markdown necessary to produce the original HTML rendering of the user-entered message, and makes mistakes in that process -- relevant to the example, it doesn't know that * and _ have different semantics despite both indicating italics.

This reinterpretation happens in other cases too: sending \( and editing that results in ( (which means the same thing, fortunately). Sending test > test (with a newline in between) and editing that results in test  > test (which fortunately also means the same thing).

I think the proper solution here would be to somehow give the user the exact same text as they entered when they sent the original message. This also follows the principle of least surprise.

Operating system

Arch Linux

Browser information

Firefox 104.0.2, reproduces on Chrome 107.0.5304.87

URL for webapp

Private server, reproduces on develop.element.io

Application version

Element version: 1.11.10, Olm version: 3.2.12; reproduces on 8eafb70-react-253129e6f283-js-52830a2a5073 with olm 3.2.12

Homeserver

Conduit; reproduces on Synapse 1.70.0rc1

Will you send logs?

No

@tomsmeding
Copy link
Author

This is even worse with usage of /html, though that might be harder to fix.
Send the following:

/html <details><summary>Summary</summary>
```
test
```
</details>

editing that gives a textarea with the following content:

Summary
\`\`\`
test
\`\`\`

which means something very different.

@tomsmeding
Copy link
Author

Another example without /html. Send the following:

\- test

edit and it becomes this:

- test

which becomes a bulleted list upon accept.

@robintown robintown added S-Minor Impairs non-critical functionality or suitable workarounds exist A-Message-Editing A-Composer O-Occasional Affects or can be seen by some users regularly or most users rarely good first issue Good for newcomers labels Nov 2, 2022
@github-actions github-actions bot added the Help Wanted Extra attention is needed label Nov 2, 2022
@robintown robintown removed Help Wanted Extra attention is needed good first issue Good for newcomers labels Nov 2, 2022
@robintown
Copy link
Member

These issues will likely be fixed when we switch over to the new rich text editor.

@t3chguy
Copy link
Member

t3chguy commented Nov 2, 2022

Duplicate of #10725

@t3chguy t3chguy marked this as a duplicate of #10725 Nov 2, 2022
@t3chguy t3chguy closed this as completed Nov 2, 2022
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Composer A-Message-Editing O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect
Projects
None yet
Development

No branches or pull requests

3 participants