jeevatkm
Disable for 10 seconds not working
The "Disable for 10 s" function does not disable ReplyWithHeader.
When the function is activated, I do get this message, as expected:
but the extension does not seem to be disabled for any length of time. Even if I immediately Ctrl-R the currently displayed message, the headers are reformatted by the extension, as if the function had not been activated. (I can see the original headers for a split-second, but they immediately change to the reformatted ones.)
Thank you in advance.
@YvesMarcoux Thanks for reporting the issue. I will analyze it and get back to you.
@YvesMarcoux I'm sorry for the delayed response, I was occupied with my personal stuff.
Can you please share your OS version and TB version?
@jeevatkm
Thunderbird 140.4.0esr (64-bit)
Edition Windows 10 Enterprise (64-bit) Version 22H2 OS Build 19045.6456
@YvesMarcoux Thanks for provding details.
I do not have Windows 10 Enterprise OS with me. I have validated the RWH v3.3.0 with the following OS(s) and TB 140.4.0esr. I'm unable to replicate the issue. Do you have any other machine to validate?
macOS Tahoe 26.1 (25B78)
Windows 11 Pro (Version 24H2, OS build 26100.4946)
Debian GNU/Linux 13.1 (trixie)
It didn't seem like an OS-related problem to me, so I did my own investigation.
I think the problem comes from the fact I have two accounts with the same email address: one POP3, one IMAP.
Since you include the accountId in the "disable-preference-name", the names didn't match between menus.mjs and compose.mjs.
I did my own fix locally, by removing the accountId from the "disable-preference-name". Now, it works.
I don't think the accountId is needed to pinpoint to a specific message, because on line 52 of compose, you retrieve the full message using only the messageId, disregarding accountId.
So here is my fix:
menus.mjs line 66:
let prefName = `disable.${message.folder.accountId}.message_${message.id}`;
replace by:
let prefName = `disable.message_${message.id}`;
compose.mjs line 46:
let isMessageLevelDisabled = await rwhSettings.get(`disable.${accountId}.message_${messageId}`);
replace by:
let isMessageLevelDisabled = await rwhSettings.get(`disable.message_${messageId}`);
If, as I think, the accountId is not needed to pinpoint a specific message, you could include it as a permanent fix in the next version.
@YvesMarcoux Ohh, so you have the same email address in two protocols. Good to know about this scenario.
I have used the account id in the temporary preference key for uniqueness. I'm not sure about the message id being a unique value across the email account on the TB client.
But what about line 52 of compose.mjs which retrieves a message by messageId only?
My understanding is that messageId gets resolved in the context of email identity/account. This is my interpretation from this documentation - https://webextension-api.thunderbird.net/en/mv3/messages.html#messages-message-id
Looking globally at the API https://webextension-api.thunderbird.net/en/mv3/messages.html I have a strong feeling that a messageId is indeed unique at any one time in the whole running application.
I will keep my local fix because (1) I honestly believe it does what is intended; and (2) I wouldn't mind even if the extension were disabled for all messages for 10 seconds.
By any chance, do you have multiple different email accounts configured in the TB? If yes, do you mind testing your modified code and please let me know?
Yes, I have 4 different accounts with 3 different email addresses (as I said 2 of the accounts have the same email address).
The testing is already done: I had already implemented it locally (right in the .xpi file) when I wrote this comment, and it works fine!
Thanks for the feedback. I will remove the account id from the preference key.