2004890 - Move loadBlockedImage() into its own module

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement)

Description

[John Bieling]

The fix for Bug 1997519 no longer requires this patch, and it was moved into a different bug for follow-up dicussions. A use-case I do see is a cache:

• Bug 1997519 is triggered by late conversion of images from replied messages.
• A WebExtension grabbing the content of the composer after the window was created could still get the content with the original URLs.
• A WebExtension manipulating that content and then writing it back to the composer caused image display errors, as the "error" event handler which would convert them was also removed - this is fixed now by https://phabricator.services.mozilla.com/D275536.
• The original idea was to manually convert images in the markdown before returning them to the caller, so that writing it back to the composer would not cause image fails - here I would have called loadBlockedImage() in the API implementation.
• We could try to skip re-converting the images when the original composer content is written back by using a cache, which could live inside ComposeUtils.mjs and have loadBlockedImage() return the value cached from the previous conversion.
• The cache could be global (same for all compose windows) or attached to each individual compose window.
• The cache could be auto-purged after about 5s, to cover only the startup situation.

Comment 1

[John Bieling]

Attachment: Bug 2004890 - Move loadBlockedImage() into ComposeUtils.sys.mjs. r=freaktechnik

To make loadBlockedImage usable outside of MsgComposeCommands.js, it
is moved into a newly created ComposeUtils.sys.mjs module.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/955ec0abbc26
Move loadBlockedImage() into ComposeUtils.sys.mjs. r=freaktechnik