Bugzilla

Thanks for the report. I assume the files issue is: https://github.com/jeevatkm/ReplyWithHeader-Thunderbird/issues/197

Thanks for making us aware of this issue, it sure is interesting. It seems to be a timing issue and modifications to (unrelated?) core code changed the point in time when the add-ons receive the content of the newly opened composer for the first time. The composer initially loads the raw content of the message and *later* replaces imap:// sources of inline images to data:// urls. Without this Thundrbird would also not display these inline images.

For unknown reasons, add-ons have received the "fixed" body in the past, but now get the original body, when they listen for newly opened compose windows. A quick dirty fix would be to wait a few ms before grabbing the content. A delay of 250ms before calling 

    let composeDetails = await messenger.compose.getComposeDetails(tab.id);

(/modules/compose.js:27)

fixed it for me. This of course not more than a quick hack. We will investigate how to resolve this.

Thanks for the report. I assume the filed issue is: https://github.com/jeevatkm/ReplyWithHeader-Thunderbird/issues/197

Thanks for making us aware of this issue, it sure is interesting. It seems to be a timing issue and modifications to (unrelated?) core code changed the point in time when the add-ons receive the content of the newly opened composer for the first time. The composer initially loads the raw content of the message and *later* replaces imap:// sources of inline images to data:// urls. Without this Thundrbird would also not display these inline images.

For unknown reasons, add-ons have received the "fixed" body in the past, but now get the original body, when they listen for newly opened compose windows. A quick dirty fix would be to wait a few ms before grabbing the content. A delay of 250ms before calling 

    let composeDetails = await messenger.compose.getComposeDetails(tab.id);

(/modules/compose.js:27)

fixed it for me. This of course not more than a quick hack. We will investigate how to resolve this.

Thanks for the report. I assume the filed issue is: https://github.com/jeevatkm/ReplyWithHeader-Thunderbird/issues/197

Thanks for making us aware of this issue, it sure is interesting. It seems to be a timing issue, and modifications to (unrelated?) core code changed the point in time when the add-ons receive the content of the newly opened composer for the first time. The composer initially loads the raw content of the message and *later* replaces imap:// sources of inline images to data:// URLs. Without this, Thunderbird would also not display these inline images.

For unknown reasons, add-ons have received the "fixed" body in the past, but now get the original body, when they listen for newly opened compose windows. A quick dirty fix would be to wait a few ms before grabbing the content. A delay of 250ms before calling 

    let composeDetails = await messenger.compose.getComposeDetails(tab.id);

(/modules/compose.js:27)

fixed it for me. This of course not more than a quick hack. We will investigate how to resolve this.

Thanks for the report. I assume the filed issue is: https://github.com/jeevatkm/ReplyWithHeader-Thunderbird/issues/197

Thanks for making us aware of this issue, it sure is interesting. It seems to be a timing issue, and modifications to (unrelated?) core code changed the point in time when the add-ons receive the content of the newly opened composer for the first time. The composer initially loads the raw content of the message and *later* replaces imap:// sources of inline images to data:// URLs. Without this, Thunderbird would also not display these inline images.

For unknown reasons, add-ons have received the "fixed" body in the past, but now get the original body, when they listen for newly opened compose windows. A quick dirty fix would be to wait a few ms before grabbing the content. A delay of 250ms before calling 

    let composeDetails = await messenger.compose.getComposeDetails(tab.id);

(/modules/compose.js:27)

fixed it for me. This is of course not more than a quick hack. We will investigate how to resolve this.

Thanks for the report. I assume the filed issue is: https://github.com/jeevatkm/ReplyWithHeader-Thunderbird/issues/197

Thanks for making us aware of this issue, it sure is interesting. It seems to be a timing issue, and modifications to (unrelated?) core code changed the point in time when add-ons receive the content of the newly opened composer for the first time. The composer initially loads the raw content of the message and *later* replaces imap:// sources of inline images to data:// URLs. Without this, Thunderbird would also not display these inline images.

For unknown reasons, add-ons have received the "fixed" body in the past, but now get the original body, when they listen for newly opened compose windows. A quick dirty fix would be to wait a few ms before grabbing the content. A delay of 250ms before calling 

    let composeDetails = await messenger.compose.getComposeDetails(tab.id);

(/modules/compose.js:27)

fixed it for me. This is of course not more than a quick hack. We will investigate how to resolve this.