Change Details

Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done. This crashes in the workaround for T3656 and it has been reported by at least one user of the Gpg4win-3.1.0-beta22 that it crashes for him without the code for T3656. While this is very stable for me and for other testers of the beta, I can confirm a very similar crash to the debug output sent by that user when I change the timing of our send invocation. This leads me to the conclusion that our async sending might be less stable then the sending in which we block outlook in the send event to do crypto. As we currently need stability over "niceness" I'll disable the async sending for now until we might figure out how to improve the timing of the send invocation so that outlook does not crash. As this is disabled now I've changed the title and marked is as wish to enable it again.

Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done. It has been reported by a user that this crashes reliably for him. While this is very stable for me and for other testers of the beta. Currently there is an option to disable async crypto because of this. But we need to figure this crash out before we can finally release this change as default.

Sending without blocking Outlook so that it is unresponsive means that we have to cancel the original send, do encrypt / sign and then invoke the send once the crypto is done. This crashes in the workaround for T3656 and itIt has been reported by at least one user of the Gpg4win-3.1.0-beta22 that it crashes for him without the code for T3656. While this is very stable for me and for other testers of the beta, user that this crashes reliably for him. I can confirm aWhile this is very similar crash to the debug output sent by that user when I change the timingtable for me and for other testers of our send invocationthe beta. This leads me to the conclusion that our async sending might be less stable then the sending in which we block outlook in the send event to do cryptoCurrently there is an option to disable async crypto because of this. As we currently need stability over "niceness" I'll disable the async sending for now until we might figure out how to improve the timing of the send invocation so that outlook does not crash. As this is disabled now I've changed the title and marked is as wish to enable it againBut we need to figure this crash out before we can finally release this change as default.