Images lost in TB 143

[PeterMacej]

The problem started after I updated to TB 143. When I reply to a message that contained inline images, the images are not displayed and sent. Only empty placeholders are visible. If I disable the extension, everything works fine.

[KsaweryD]

I confirm exactly the same problem - also with TB 143 and the RWH version 3.3.0 extension running. Noticed only after the latest Thunderbird update. Photos embedded in the content of the email to which I am replying/forwarding are broken/not attached (an empty rectangle remains). It seems that there is a change in the way the photo is referenced

• without the extention (visible images), the image address is as follows: data:image/[format];filename=[name.format];base64,[image_code]
• with extention on (broken images] , the image address is as follows: imap://[account_address]@[server_address]:[port_no]/fetch%[folder_address]?header=quotebody&part=[number]&filename=[name.format]

Exactly the same behavior causes an alternative add-on, i.e., Advanced Composer version 3.2.1 by Prasetyo S with the header modification module enabled.

[JackMauro]

I think that Thunderbird changed some interface because almost all "reply header" extensions have the same problem, but I don't know if it's a bug or an intentionally made change.

[ovskitovski]

Can confirm the same in Ubuntu 24.04 Thunderbird 143.1 with RWH 3.3.0

When my system was overloaded and slow, I could see how the image was loaded, then the plugin overwrote the reply header and at the same time the image disappeared.

[p-palai]

The ChangeQuote Add-on for similar functionality for TB144.0.1 (64-bit) seems to be working fine with the inline image not getting lost.

[ViperGeek]

Stating the obvious, this is still broken in TB 144.0.1 (64-bit) on Windows 11.

[jobisoft]

https://bugzilla.mozilla.org/show_bug.cgi?id=1997519#c1

[tomdereub]

Bug still present with thunderbird 140.4.0esr while transferring a mail, with these extensions installed :

[jeevatkm]

Hi @jobisoft - I have checked the issue link you have provided, thanks. If I add an artificial delay of 250ms, will it do the trick of this image issue, correct? Also, is there a better systematic resolution coming up in the future?

[jobisoft]

I filed a patch which will address this in the WebExtension API: https://phabricator.services.mozilla.com/D270839

Once this has been accepted, this issue is going to be fixed not only for the RWH add-on, but for all extensions which act on freshly opened compose windows. It will first be fixed on Thunderbird Daily and Beta and then Release, probably also on ESR 140 a bit later.

[jeevatkm]

Thanks @jobisoft for the details. In the meantime, I will apply this delay workaround.

[benito32rus]

I filed a patch which will address this in the WebExtension API: https://phabricator.services.mozilla.com/D270839

Once this has been accepted, this issue is going to be fixed not only for the RWH add-on, but for all extensions which act on freshly opened compose windows. It will first be fixed on Thunderbird Daily and Beta and then Release, probably also on ESR 140 a bit later.

Dear all, good afternoon! Please help someone who isn't very good at programming. Did I understand correctly that if I download the patched files from the link above and replace them, this problem will be solved? If you don't mind, please provide step-by-step instructions.

[jeevatkm]

@benito32rus - The above patch file is a TB fix to address issues for all the TB add-ons related to this image issue. It is not a RWH add-on patch. Tonight, I aim to create a RWH release with the workaround suggested by @jobisoft.

[jeevatkm]

Hello - I added the workaround of artificial delay as suggested. Can anyone try it out and share feedback?

PS: Please rename the file extension after the download from .zip to .xpi replywithheader-v3.3.1-dev.zip

[benito32rus]

Hello - I added the workaround of artificial delay as suggested. Can anyone try it out and share feedback?

PS: Please rename the file extension after the download from .zip to .xpi replywithheader-v3.3.1-dev.zip

Good afternoon! I tried it, but unfortunately it didn't work for me(

[JackMauro]

Hello, I think 300ms may not be enough time for me: for some email with one or few images, the workaround works, but for some email with "a lot" of images (mostly small images used in signature quoted and requoted dozens of times), images are not displayed. For examples on my setup, a mail with 14 images (total email size: 339kb) is wrong, a mail with 12 images (total email size: 283kb) is correct.

[jobisoft]

The fix in the API still needs some time before it reaches ESR or Release. To have a solid solution for the add-on in the meantime, @jeevatkm could look at the actual body and use a delay loop until no mailnews urls are present.

async function hasNoMailnewsUrls(tabId) {
    // This function could act on the actual DOM by executing a compose script
    // which might be more reliable, but for simplicity of the example we just
    // check the body text here.
    const details = await browser.compose.getComposeDetails(tabId);
    return (
        details.body.includes("imap://") || 
        details.body.includes("mailbox://")
    )
}

for (let i=0; i<10; i++) {
    if (await hasNoMailnewsUrls(tabId)) {
        break;
    }
    await new Promise(resolve => setTimeout(resolve, 200));
}

This waits at most 2s.

[jeevatkm]

Thanks @jobisoft.

@benito32rus @JackMauro I have added the loop-based check as mentioned in the above comment. Can you please try it out and share feedback?

PS: Please rename the file extension after the download from .zip to .xpi replywithheader-v3.3.1-dev.zip

[jobisoft]

I am sorry, you need to invert the logic.

// This is workaround method to resolve image issue GH#197
// https://github.com/jeevatkm/ReplyWithHeader-Thunderbird/issues/197#issuecomment-3526481692
async function hasNoMailnewsUrls(tabId) {
    // This function could act on the actual DOM by executing a compose script
    // which might be more reliable, but for simplicity of the example we just
    // check the body text here.
    const details = await messenger.compose.getComposeDetails(tabId);
    return (
        !details.body.includes("imap://") &&
        !details.body.includes("mailbox://")
    )
}

My original code returned true if it included a mailnews url, but we want it to return true if it does not. Sorry.

[jeevatkm]

@jobisoft Thanks for the correction. I updated the code.

@JackMauro @benito32rus Can you please try it out and share feedback?

PS: Please rename the file extension after the download from .zip to .xpi replywithheader-v3.3.1-dev.zip

[benito32rus]

@jobisoftСпасибо за исправление. Я обновил код.

@JackMauro @benito32rus Можете ли вы попробовать и поделиться отзывом?

PS: Пожалуйста, переименуйте расширение файла после загрузки .zipна .xpi replywithheader-v3.3.1-dev.zip

@jeevatkm Good afternoon! I checked the changes on TB 145.0. If the message is not overloaded with pictures, then it works fine. If the message thread is large (lots of pictures), then the result is bad. Anyway, thanks a lot, it's already possible to work with it.

[jeevatkm]

@benito32rus Thanks for testing and sharing your feedback.

[jeevatkm]

Will be released in v3.3.1