fix: replace square bracket errors with proper message errors #4988
Conversation
link2xt
force-pushed
the
link2xt/no-square-bracket-errors
branch
from
2123860 to
6c22b11
Compare
Square bracket errors were introduced before we had proper errors, hide the images, reset system messages to non-system messages and may themselves be replaced with "better message" in receive_imf.
link2xt
force-pushed
the
link2xt/no-square-bracket-errors
branch
from
6c22b11 to
b937f24
Compare
|
that would remove the hiding of messages in guaranteed-e2ee groups, right? maybe sth. for after 1.42 |
yes and that is a feature! the messages will still be marked with the red error sign, but at least usable, the weird brackets messages should be considered a bug IMHO, they are confusing and 99% of the cases get on the way and screw the message you received without possibility to get access to voice or images files etc |
|
On Mon, Nov 13, 2023 at 08:43 -0800, Asiel Díaz Benítez wrote:
> that would remove the hiding of messages in guaranteed-e2ee groups, right? maybe sth. for after 1.42
yes and that is a feature! the messages will still be marked with the red error sign, but at least usable, the weird brackets messages should be considered a bug IMHO, they are confusing and 99% get on the way and screw the message you received without possibility to get access to voice or images files etc
The "weird brackets" are a cheap method of *not* showing the message
because it violates e2ee-guarantees.
The design goal here was to not show messages in a green-checkmarked chat
if they are not "proper": at least you need to do another click/tap.
That the message (info) behind the click is a bit ugly is unfortunate
but also incentive to fix the situation.
|
There was no goal (only path): deltachat/deltachat-core#559 |
|
Signal at least at some point had this "Tap to process and display", something like an undownloaded message: Ideally unverified message should be an error type like this, so the message is not displayed immediately but can be revealed and then hidden once you reopen the chat. |
|
In addition to the message in square brackets, there is also the problem that the message is also treated as reactions. |
|
On Mon, Nov 13, 2023 at 10:23 -0800, link2xt wrote:
> The design goal here was to not show messages in a green-checkmarked chat if they are not "proper"
There was no goal (only path): deltachat/deltachat-core#559
It was just a hotfix for this message appearing in a split group, and a fix was to add this message to verified group. But because it was impossible to display any error, the message is replaced with an error.
The underlying reasoning for #559 (not explicit, admittedly) was to
only have "proper" messages shown in verified chats.
Anyways, while reading other PRs i wonder
if we could do the following (probably rather post-1.42)
- display a "show-anyway" button at the same position/way as the "download" button
- once clicked, the message appears properly with a red-exclamation mark.
|
|
For discussion there is a #4999 issue now. |
|
I tried this, currently it leads to messages displayed just w/o the padlock in 1:1 verified chats:
UPD: I tested it on top of my changes keeping 1:1 chat protection, that's why there is no message about a broken protection. But still, the error isn't displayed and that's the problem. UPD: Finally, i think, i'm also for merging this. DC CLI is easy to improve here. |
|
I already merged this into DeltaLab, thanks a lot! even if not a perfect solution (the content-warning first then displaying) it is a lot better than current situation with weird messages, attachments lost, and weird bug in reactions from unknown senders (see screenshot above) |
Square bracket errors were introduced before we had proper errors, hide the images, reset system messages to non-system messages and may themselves be replaced with "better message" in receive_imf.