Open
Bug 924358
Opened 12 years ago
Updated 3 years ago
Message with attachment marked as read automatically despite setting to never mark read
Categories
(Thunderbird :: Folder and Message Lists, defect)
Thunderbird
Folder and Message Lists
Tracking
(Not tracked)
NEW
People
(Reporter: ws.bugzilla, Unassigned)
Details
I have Thunderbird configured to never mark messages as "read" automatically. This works most of the time, but messages with attachments occasionally get marked as "read" when I view one.
Most of the time this doesn't actually happen, even for messages with attachments, so it's not easily reproducible. But every now and then it does, and the only thing that is true every single time is that the message affected invariably has attachment(s).
This happens on an IMAP account.
I've observed this for at least a year, during which time it happened a few dozen times. Found a couple of similar reports: bug 676811, bug 673881. I think it *may* be triggered by attachment download like mentioned in the linked bugs, possibly by the automatic download required to show inline images. There's also bug 626845.
I’ve “always” seen this bug (for at least the 5 past years). And it’s still occurring on latest Thunderbird.
And I see this for almost all emails with an attachment. And never for mail without attachments.
Rectification: Latest Thunderbird (52.0) on Linux seems not to show this behaviour, or at least not always. But Thunderbird 45.8.0 on Windows behaves the wrong way systematically (if there is an attachment), on the same messages.
For some reason, I've just observed this very annoying bug. After troubleshooting, I believe that I have isolated the cause to a particular Add-On: Enigmail.
Could anyone who experiences and/or can still reproduce this bug and please advise whether
1. they are using Enigmail, and
2. unchecking the Enigmail preference "Only download attachments when opened (IMAP only)" resolves the problem?
The Enigmail preferences is reached from the Enigmail menu -> Preferences -> Advanced tab. You may have to click the "Display Expert Settings and Menus" button to see the Advanced tab.
Unchecking this preference resolved the problem for me with Thunderbird 52.5.2 and Enigmail 1.9.9 on Mac.
Comment 5•8 years ago
|
||
1. Enigmail does contain any function that would change the "Read" status.
2. The "Enigmail" preference "Only download attachments when opened (IMAP only)" is nothing more than a frontend for the Thunderbird setting "mail.server.default.mime_parts_on_demand". That setting exists whether Enigmail is installed or not
3. The recommended setting when using Enigmail is to turn the feature OFF, i.e. to disable the checkbox, otherwise large emails can't be decrypted.
Nice to have you here, Patrick!
I'm sorry to have to press this, but the empirical evidence is that Enigmail is implicated in this bug: observing the bug and then simply disabling Enigmail and restarting Thunderbird resolves the bug. Thunderbird's "mail.server.default.mime_parts_on_demand" preference defaults to true and I do not observe this bug with this default when Enigmail is disabled.
Patrick, could you please try to reproduce this bug on your installation?
I've noticed there are additional times where Thunderbird disregards a 'mailnews.mark_message_read.auto = false' setting and automatically marks the message currently selected in the thread pane read:
1. when replying to a message (Message menu -> Reply, or its keyboard shortcut)
2. when viewing a message's source (View menu -> Message Source, or its keyboard shortcut)
Note: the message will only be marked read if the message has to be retrieved from the IMAP server, in both cases. Once the message is cached locally then neither of these actions will mark an unread message as read. These two cases occur even when Enigmail is disabled.
Probably not relevant to the bug, but an annoying artefact of it, is that the marking as read can be immediate *or* it can take place several seconds later.
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•