In our case getting the multipart body is not enough, we want to pass the whole message to the engine as it's written in the topicbox question above. Getting the whole message is not easy in the component, as the URI we get there does not work with the most common methods lise nsIMessenger.msgHdrFromURI.
Another problem with this approach is that after decrypting the message we want to use its contents to modify parts of the view, and this is not possible from the component interface.
The component can only return a different MIME message that will be parsed by the mime proxy and showed by the interface. While the component handler is executed, there is no way to refer to the thunderbird window.
If the component runs in isolation from the view then we need to decrypt the message twice, once for passing the decrypted attachments as a result of the component handler and a second time for updating the parts of the reading window with the contents coming from the decrypted message.
We want to connect the decryption handler component with the view scope for the reasons explained above. Such a connection is based upon some assumptions, for instance we assume that the view will always be called after the component in the case of decryption (for encryption, the opposite might be true).
The decryption handler is asynchronous and experiments with Thunderbird 68.4 show that we can postpone the resolution of the handler indefinitely, so we can wait for a promise to be resolved by the view.
This is the reason why the component control flow is depending on the view control flow. Every time the decryption component is created it adds an handler that can be called by the reading view.