Hello Maxime.L
Thank you for reaching out to Microsoft Q&A forum regarding the issue with your Outlook Mail Compose Add-in, specifically the re-triggering of the onMessageSendHandler function in Outlook Desktop clients (both classic and New Outlook) when using the PromptUser send mode override for inline attachments. This behavior appears to be a client-specific handling in Outlook Desktop on Windows, where selecting "Send Anyway" in the prompt dialog causes an immediate retry of the send operation. This retry re-invokes the handler without changes to the message state, resulting in the prompt reappearing. In contrast, Outlook on the web (OWA) processes the override and sends the email without re-triggering the event.
To confirm, this aligns with known differences in how desktop clients manage event retries and user overrides in Smart Alerts scenarios, though it's not documented as a bug.
As a workaround, you can implement a timestamp-based check to detect and bypass the rapid re-trigger. This assumes the desktop retry occurs almost immediately (within approximately 2 seconds), while manual re-sends after user modifications would take longer. Here's how to apply it:
- Declare a global variable outside the function to track the last prompt timestamp, e.g.:
let lastPromptTime = 0; - In your
getAttachmentsCallbackfunction, after checking for non-inline attachments and before prompting for inline ones, add a check like this:// Check if this is a rapid re-trigger (likely from "Send Anyway" on desktop) const now = Date.now(); if (now - lastPromptTime < 2000) { // Adjust threshold if needed (e.g., 1000-3000 ms) event.completed({ allowEvent: true }); return; } // Set timestamp and prompt lastPromptTime = now;
You can adjust the 2000 ms threshold based on your testing to balance catching auto-retries without interfering with quick manual actions. This approach should resolve the double-prompt issue on desktop without affecting OWA behavior.
If this doesn't fully resolve it (e.g., if the re-trigger timing varies), consider setting the send mode to "promptUser" in your unified manifest's autoRunEvents.events.options.sendMode property instead of overriding it at runtime. Then, remove sendModeOverride from the code for the inline case (keeping it as a soft prompt with "Send Anyway"). If you need stricter blocking in the no-attachments branch, override to Block or SoftBlock there. This might avoid the retry behavior altogether, as manifest-level modes are handled more consistently by the client.
I hope this information can clarify your concern. If you have any additional concern, feel free to comment below. I be more than happy to assist.
If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.