We are seeing an issue in Outlook for Mac (version 16.22.211.0) around "roundtripping" the mail body with Context.mailbox.item.body.getAsync and Context.mailbox.item.body.setAsync when the mail body contains images. In the simplest version of this case, we are simply getting the mail body as HTML with getAsync, and then writing back the exact same HTML with setAsync.
For example:
function roundtripMailBody() {
Office.context.mailbox.item.body.getAsync(Office.CoercionType.Html, (result) => {
if (result.status === Office.AsyncResultStatus.Failed) {
return;
}
const bodyHtml = result.value;
Office.context.mailbox.item.body.setAsync(bodyHtml, { coercionType: Office.CoercionType.Html });
});
}
If the mail body contains an image (for example, from a signature, or from a user pasting an image in, or from a user inserting an image using the Pictures button in the ribbon), calling the function above will result in the images being broken when the mail is opened by a recipient. Interestingly, the image doesn't appear broken in the compose window immediately after writing to the body with setAsync; it only appears broken after sending, or when closing the compose window and reopening the mail from Drafts.
Here is some example HTML retrieved via body.getAsync:
<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 15 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>
</head>
<body lang=EN-US>
<div class=WordSection1>
<p class=MsoNormal><img width=256 height=256 style='width:2.6666in;height:2.6666in'
id="Picture 2"
src="~WRS%7b81702A75-3806-F94F-ACF1-448451D74C09%7d.fld/image001.png"></p>
<p class=MsoNormal> </p>
</div>
</body>
</html>
And after writing that HTML to the body via body.setAsync, this is what the result of a subsequent call to body.getAsync returns:
<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 15 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>
</head>
<body lang=EN-US>
<div class=WordSection1>
<p class=MsoNormal><img width=256 height=256 style='width:2.6666in;height:2.6666in'
id="Picture 2"
src="~WRS%7b81702A75-3806-F94F-ACF1-448451D74C09%7d.fld/image001.png"
style='height:2.666in;width:2.666in' alt=image001.png></p>
<p class=MsoNormal> </p>
<p class=MsoNormal> </p>
</div>
</body>
</html>
Very little appears different from a plain HTML perspective. If the compose window is closed at this point and then reopened from the Drafts folder, body.getAsync returns the same thing, but the image no longer renders. If the mail is sent and then its contents inspected (in OWA for ease of access) the body is:
<div lang="EN-US">
<div class="x_WordSection1">
<p class="x_MsoNormal"><img data-imagetype="External" src="file:////Users/shannon/Library/Containers/com.microsoft.Outlook/Data/Library/Application%20Support/Microsoft/Temp/~WRS%7b81702A75-3806-F94F-ACF1-448451D74C09%7d.fld/image001.png" width="256" height="256" id="x_Picture_x0020_2" alt="image001.png" style="width:2.6666in; height:2.6666in"></p>
<p class="x_MsoNormal"> </p>
</div>
</div>
The src is clearly wrong on the recipient end (pointing to a local file on my machine that doesn't exist). What is the proper way to rewrite the mail body without corrupting the src? This stackoverflow question and this one as well seem tangentially related to this problem, but we are currently only seeing this problem when composing in Mac Outlook (Windows Outlook 2013, Windows Outlook 2016, and Outlook Web App are all behaving as expected). We're also not seeing any reference to a cid in the Mac Outlook HTML blob, so even if we did want to replace the src with the base-64 encoding from the Rest API, we don't know how we would.
Is this behavior expected? Any ideas on how to resolve it?
