deltachat-core-rust icon indicating copy to clipboard operation
deltachat-core-rust copied to clipboard

Published 20 hours ago • verified publisher icon deltachat

No read receipts for encrypted messages after manually overriding configured size limit of "Auto-Download Messages" in chat

Open gerryfrancis opened this issue 3 years ago • 4 comments

  • Operating System (Linux/Mac/Windows/iOS/Android): Android 11.

  • Delta Chat Version: 1.26.2 (nightly build).

  • Expected behavior: Read messages are confirmed by read receipts (when enabled), even when the size of a message received exceeds the limit configured in "Auto-Download Messages" after downloaded manually.

  • Actual behavior: Read receipts are not sent back when a) the message is encrypted, and b) the message size is bigger than the configured limit in "Auto-Download Messages", and c) the message is confirmed to be downloaded manually in the respective chat.

  • Steps to reproduce the problem: -- Verify that "Read Receipts" is enabled. -- Configure "Auto-Download Messages" and set a certain message size limit. -- Receive an encrypted message of a bigger size than the limit you set before. (Note: It must be an encrypted message.) -- Confirm to download the message anyway. (Result: Delta Chat does not return a read receipt to the sender of this message.)

  • Screenshots: N/A.

  • Logs: N/A.

  • Remark: A read receipt is sent back when the message downloaded manually is an unencrypted one.

gerryfrancis avatar Jan 13 '22 21:01 gerryfrancis

I cannot reproduce this issue with the latest nightly build on Android anymore, so I am closing here. :)

gerryfrancis avatar May 09 '22 09:05 gerryfrancis

Unfortunately the issue has reoccured (for me in the very latest 1.36.2 nightly build), so reopening...

gerryfrancis avatar Apr 08 '23 13:04 gerryfrancis

The issue still exists in version 1.42.0.

gerryfrancis avatar Nov 16 '23 09:11 gerryfrancis

The reason of the bug reappearance is 5f00fc4e277b1802ce623da18770f50ba191def4 which removes updating msgs.state to Seen when a message is replaced by the fully downloaded one. But it's correct and there's even a test on this, test_download_later(), -- a user maybe hasn't yet seen the downloaded message (downloading may take time), so the state mustn't be changed only because of the finished download. The message must be marked as seen later, by the same logic as usual messages, but this doesn't happen for some reason...

UPD: Afaiu, UIs must mark messages as seen calling message::markseen_msgs(), so probably this is not a core lib issue. CC @r10s @link2xt

UPD: Also reproduced this with DC Desktop.

UPD: The mentioned commit isn't the reason of the bug reappearance because it's a very recent change. Still, the issue is likely in UIs.

iequidoo avatar Nov 25 '23 02:11 iequidoo