OfficeDev / office-js

A repo and NPM package for Office.js, corresponding to a copy of what gets published to the official "evergreen" Office.js CDN, at https://appsforoffice.microsoft.com/lib/1/hosted/office.js.
https://learn.microsoft.com/javascript/api/overview
Other
648 stars 92 forks source link

Outlook Desktop/OWA corrupts `<img>` `src=` tag #1660

Closed wsoccorsi-yw closed 3 years ago

wsoccorsi-yw commented 3 years ago

Some users using our add-in have experienced images we insert with appendOnSendAsync consistently lose their src attribute. This src attribute then points to a white block called Image001.png. As mentioned in the title this also happens with prependAsync and setAsync but for the sake of brevity and clarity I will be using AoS as the example.

Please note that we only have one piece of the puzzle, we essentially give you the HTML and hope its inserted right, so maybe this is an Outlook setting or some message pre processing stripping. Below is my example of where this is going wrong but, since this is happening on all three HTML insertion methods it's up in the air but. I can point in the direction where things go wrong but, the solution might be broader than this.

This only applies to some users, they have never been able to use AoS because of this issue, receiving constant corruption.

Expected Behavior

HTML inserted with appendOnSendAsync keeps its attributes IE inserting <img src="my_path"> comes through on the recipient side as <img src="my_path">

Current Behavior

HTML inserted with appendOnSendAsync keeps its attributes IE inserting <img src="my_path"> comes through on the recipient side as <img src="path_to_Image001.png">

Steps to Reproduce, or Live Example

Here are the HTML examples and AOS context. But, please note I am unable to reproduce this issue. I can however provide that this user can send any image they want inline without a problem. Therefore it is not an inline image issue or they would be unable to attach any images. They are also allowed to download images and have all emails sent as HTML.

What I send and how I send it:

HTML: <img id="m_-<redacted>_x<redacted>" src="https://ci5.googleusercontent.com/proxy/<redacted>_<redacted>-_<redacted>=<redacted>ft#https://t.yesware.com/t/<redacted>/<redacted>/spacer.gif" class="CToWUd">

JS to send:

 public appendOnSend(html: string): Promise<Office.AsyncResult<void>> {
        return new Promise<Office.AsyncResult<void>>((resolve, reject) => {
            (Office.context.mailbox.item.body as any).appendOnSendAsync(
                html,
                { coercionType: Office.CoercionType.Html },
                (asyncResult) => {
                    if (asyncResult.status === Office.AsyncResultStatus.Succeeded) {
                        console.log('native tracking succeeds');
                        resolve(asyncResult);
                    } else if (asyncResult.error) {
                        reject(asyncResult.error);
                    } else {
                        reject(asyncResult);
                    }
                }
            );
        });
    }

This promise returns success, and this is what I receive: <img id="m_<redacted>_x<redacted>" src="https://mail.google.com/mail/u/0?ui=2&amp;ik=b7fc2dbf1d&amp;attid=0.1&amp;permmsgid=msg-f:1691871115760583649&amp;th=177abbd0dca743e1&amp;view=fimg&amp;sz=s0-l75-ft&amp;attbid=ANGjdJ9jyhAM0By7vSUTyr7hLDJEO_ZfagVurhxDhPiykabXGauoY6RJuIgs43FPWGTUmf3JfQHw8aludTM83NwgfdvXastVDy-njNOGp5eHC3RxXJWLjVXhI-HXCB8&amp;disp=emb" data-image-whitelisted="" class="CToWUd">

This points to an image called: Image001.png or in show original src==3D"cid:image001.png@01D7048B.91284660"

At this point you may be asking if the user can send this img inline? And they can without the src getting changed. So this is why I point at the appendOnSendAsync API. For if we don't give the HTML to this function (or any of the other API's) we see a correct insertion.

Context

I'd like for HTML inserted with append on send to come through the other end unchanged.

Your Environment

Windows Desktop, Outlook Version 2012 (Build 13530.20316) But the user can repro on OWA.

Useful logs

Just AOS promise returns success, 'native tracking succeeds' is printed.

Please let me know if you need anything else. Thanks in advance :D

exextoc commented 3 years ago

A few clarification questions,

I also notice that the change is from https://ci5.googleusercontent.com/... to https://mail.google.com/... Have you tried images hosted in other services?

wsoccorsi-yw commented 3 years ago

@exextoc I'll do my best to answer these: "You only see the issue if img tag getting modified for some, but not all users?" => Yes only some users have this happen, and they can reproduce this consistently every time. Never being able to send an image tag.

"When the gets modified, do you know if it gets corrupted by sender's client? Did you try to getBody and check the result immediately after prePendAsync returns (noting that you cannot try this with AOS)? What about sent-items? Here, I am seeing if we can identify when the change might have occurred." => Since I cannot reproduce this on my end I cannot dive in step by step. What I can tell you is if they insert this image without these methods everything is fine. For sent items I might have to say the same thing. Step by step all I can say is AOS returns success but what I see on my end is a different path.

"Is this always reproducible with this particular sender, particular recipient, particular sender-recipient pair? Do we know if other senders in the same org are impacted?" => There is no pair or combination that causes this. One user we have can send an email to anyone on my team and have this path corrupted, never being able to insert an img tag properly. They tried with OWA/Outlook Desktop all with the same issue.

"Is there difference in behavior for recipients in the same org vs external to the sender?" => Sadly only one user at this organization, I'm assuming you are pointing to an IT set up?

"Do you know if the impacted sender is on Exchange online or are they using on-premise accounts?" => This user is not on exchange.

"I also notice that the change is from https://ci5.googleusercontent.com/... to https://mail.google.com/... Have you tried images hosted in other services?" => I haven't, I believe thats just because I opened this in gmail, but opening in outlook I receive: <img data-imagetype="AttachmentByCid" originalsrc="cid:177d4a5d5454cff311" data-custom="AAMkADZiMTE2NGE4LWJlYTktNGVlMS05NzhiLTY5NjBiNWE0NDRkZQBGAAAAAAB7cCDDdFlzQpQCHoyneoxJBwCT72OlKfxYSbGvOkmiynlXAAAAAAEMAACT72OlKfxYSbGvOkmiynlXAADrQDZxAAABEgAQADiJJwePNsdFsDo9H5z9acM%3D" naturalheight="0" naturalwidth="0" src="https://attachments.office.net/owa/wsoccorsi%40yesware.onmicrosoft.com/service.svc/s/GetAttachmentThumbnail?id=<redacted> id="x_m_<redacted>Picture_x0020_1" style="width: 29.99pt; height: 29.99pt; cursor: pointer;" crossorigin="use-credentials">

exextoc commented 3 years ago

Thanks for the answers. Based on what you described with how the path look opening by recipients in gmail and Outlook (assuming OWA or Outlook on MAC here), it looks like the attached src link from the sender is converted to an attached image. By attached image, I mean an image attachment, and the image that is shown inline in the body referencing the attachment.

Let's consider where the conversion can occur. Since both Outlook and Gmail recipients are getting the attachment instead of image link, my first suspect is on the sender side. And you indicate that the sender sees the same conversion with both sending from both OWA and Outlook Desktop, this makes me suspect sender's server side, considering OWA and Outlook desktop clients handle message body and attachments quite differently.

To validate the suspicion, ideally, we should try to examine the message in Sent-item. It would be best to save the message as a .msg from desktop to examine the raw item properties and see if what the image link looks like there. I suggest using .msg because we get more client rendering additions when we use browser client (say OWA) and examining content with browser debugger.

Similarly, we can also confirm that the recipients are getting an attachment by also saving the received item as .msg, or in gmail, using 'Download Message'.

The short version - we need to save .msg or download message from both sender's sent-item and recipients to try to narrow down where the change is happening.

wsoccorsi-yw commented 3 years ago

@exextoc Sorry for the late response, thats a very interesting insight! I would agree it is with the Sender as well. Just because it doesn't happen to everyone, and based on the Sender happens 100% of the time.

So I am getting a user to download the email from their sent folder and send it to us so we can narrow this down. Thanks for working with me here. I'll post back here when I have these answers.

wsoccorsi-yw commented 3 years ago

I thought I'd mention that we have a user who only gets this on Outlook Desktop for Windows but not OWA which I find interesting and might change some of your suspicions.

exextoc commented 3 years ago

Got it on that there's a user hitting the issue on Outlook desktop and not OWA. It will still be useful to examine the sent-items to know if the attachment change has happened. For these affected users, it will be useful to know the Outlook desktop build version, Windows version (may be less important), and if applicable, OWA version. OWA version is closely related to the user's email server version. If we suspect server side issue, it will be useful to know server version to help us narrow down where to look deeper.

I realize some of this can be more difficult to get. Getting the sent folder item should help us narrow down a bit.

wsoccorsi-yw commented 3 years ago

Hey @exextoc sorry for the wait the user just sent the original/downloaded message from Outlook Desktop looks to be identical: <img id=3D"_x0000_i1025" src==3D"cid:image001.png@01D70B90.B1961C40">

exextoc commented 3 years ago

Following up with devs who own this code, they are not aware of any client side feature that would do this. Since this is happening with only one user, is it possible they have a COM add-in (or something else) that is doing this on client side?

The other thing to try is to compare the complete HTML from a saved draft (BEFORE it was sent), and the complete HTML from the Sent Items folder AFTER the email has been sent. If privacy is not an issue on an email like this, sending us the .msg files could help us track down the issue. (having the full HTML helps us determine what other elements may have been changed during send)

wsoccorsi-yw commented 3 years ago

@exextoc Sure I'll work on getting that information for you. But we technically don't insert the HTML until "on send" so I am wondering how this helps?

And for clarification we have about 5 users reporting this issue.

exextoc commented 3 years ago

I guess that makes this more problematic to debug.

If you have a repro environment I would suggest writing a test add-in that inserts the image via prependAsync/setAsync/setSelectedData. Grab the HTML body. Send the Mail. Then compare the HTML body afterward.

You could probably do this with ScriptLab (on the Office Store) and write a quick snippet that does this.

I understand setting up something like that on a customer's machine may be difficult though.

If that isn't possible, I guess providing the .msg files from the sent message folder after the message has been delivered may provide some clues as to what is happening.

wsoccorsi-yw commented 3 years ago

So this is actually a wonderful idea and I've got an idea on how to implement it. Since I can't repro on my end I will have to create a test environment that stops an email from sending on the users end. This will take some time but we at least have a way forward here. Thanks!

wsoccorsi-yw commented 3 years ago

Before I grab that info here are the sent and inbox emails with personal info redacted:

Github doesn't let me upload as a .eml, so just change the extension on your end.

Sent: sent.txt

Inbox: inbox.txt

exextoc commented 3 years ago

Just to clarify inbox.eml = the email after it was sent, and in the recipients inbox. sent.eml = the email from the sender's sent items folder?

wsoccorsi-yw commented 3 years ago

Just to clarify inbox.eml = the email after it was sent, and in the recipients inbox. sent.eml = the email from the sender's sent items folder?

Yup!

exextoc commented 3 years ago

Yeah so ultimately, it's unclear why this is not a deterministic issue for all users, and only this certain subset of users is hitting this issue. (I assume they're hitting it 100%?) If there is anything unique about the people that are hitting this issue, that may help us determine what the root cause is, please forward along that info. (i.e. I'm hoping the messages may help us figure out what is going on, but I have no idea if it will actually lead us to the root cause)

thanks for all your help in this so far.

wsoccorsi-yw commented 3 years ago

Emerging here again!

@exextoc Right back at you thanks for helping out.

I've got an AoS call right to drafts before sending and some good news is this is where things are happening!

Note I did this by creating a delay on Outlook Desktop, Sending the Email but it stays in the outbox and then I bump it to drafts. Once in drafts I can look at the message still in compose. Maybe this process messes it up so I would just like to mention that.

HTML in drafts inserts this img as:

<p class="MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;line-height:0%">
<span lang="EN-US" style="font-size:1.0pt; display:none">
<img data-imagetype="AttachmentByCid" originalsrc="cid:image002.png@01D715D0.DA639860" data-custom="AAMkAGQ1MGI3Mzk5LTQ1MWYtNDdhZi1iZDcyLTU3MzNkZmRkNzYyZABGAAAAAABUuy1CbKiMSL1R4pXs4jTVBwA980z6FY7fRYdVU6evl3RUAAAAAAEPAAA980z6FY7fRYdVU6evl3RUAAKe7LDyAAABEgAQAP4c2WAp2fpOl5KHYdl2UNY%3D" naturalheight="0" naturalwidth="0" src="https://attachments.office.net/owa/redacted_user_name%40flexera.com/service.svc/s/GetAttachmentThumbnail?id=AAMkAGQ1MGI3Mzk5LTQ1MWYtNDdhZi1iZDcyLTU3MzNkZmRkNzYyZABGAAAAAABUuy1CbKiMSL1R4pXs4jTVBwA980z6FY7fRYdVU6evl3RUAAAAAAEPAAA980z6FY7fRYdVU6evl3RUAAKe7LDyAAABEgAQAP4c2WAp2fpOl5KHYdl2UNY%3D&amp;thumbnailType=2&amp;token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjMwODE3OUNFNUY0QjUyRTc4QjJEQjg5NjZCQUY0RUNDMzcyN0FFRUUiLCJ0eXAiOiJKV1QiLCJ4NXQiOiJNSUY1emw5TFV1ZUxMYmlXYTY5T3pEY25ydTQifQ.eyJvcmlnaW4iOiJodHRwczovL291dGxvb2sub2ZmaWNlLmNvbSIsInVjIjoiZTI5MWYxY2ZkYTE0NGM3NThmY2UzNGJmMTFlNzMzOWYiLCJzaWduaW5fc3RhdGUiOiJbXCJrbXNpXCJdIiwidmVyIjoiRXhjaGFuZ2UuQ2FsbGJhY2suVjEiLCJhcHBjdHhzZW5kZXIiOiJPd2FEb3dubG9hZEA5MTAzNGQyMy0wYjYzLTQ5NDMtYjEzOC0zNjdkNGRmYWMyNTIiLCJpc3NyaW5nIjoiU0lQIiwiYXBwY3R4Ijoie1wibXNleGNocHJvdFwiOlwib3dhXCIsXCJwdWlkXCI6XCIxMTUzOTA2NjYxMTk3NTkzNjE0XCIsXCJzY29wZVwiOlwiT3dhRG93bmxvYWRcIixcIm9pZFwiOlwiOWYyZGUzMGUtNjgyYy00YjgyLWIyYjYtZDhhMmJiMDY2NzUwXCIsXCJwcmltYXJ5c2lkXCI6XCJTLTEtNS0yMS0zODM4MzYyMDM4LTE0MDAyMTg3MjYtMjQ5NTAyNDc5Ni0xNzIyNDg0OVwifSIsIm5iZiI6MTYxNTM5Mjc4NCwiZXhwIjoxNjE1MzkzMzg0LCJpc3MiOiIwMDAwMDAwMi0wMDAwLTBmZjEtY2UwMC0wMDAwMDAwMDAwMDBAOTEwMzRkMjMtMGI2My00OTQzLWIxMzgtMzY3ZDRkZmFjMjUyIiwiYXVkIjoiMDAwMDAwMDItMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwL2F0dGFjaG1lbnRzLm9mZmljZS5uZXRAOTEwMzRkMjMtMGI2My00OTQzLWIxMzgtMzY3ZDRkZmFjMjUyIiwiaGFwcCI6Im93YSJ9.KFT1gGU8v1qw8l6mO4QZBZyqjJyy7-K1J37ukfAgosVsOB3jHiHdV-A7iqCHyOvylatl3EAWScMuwvcX36E9Vf6Ubl-YBhzv3YMUr7RZ_aQ34mi1ZYO-syDtidHH5YrkWeSe7Ai1X1MZSoEdycVQO0OhW2Z16PBws_1xStVyMPfEbsGSO2RJvotFggq0na748Laof5oMV-bvyJw8y6n4h30BzAbNDEoDLwb5W8kmet5kkQWh46-ZMFcalopa5ogWIqse7yoJ92HTIxybohJ78NcfQ70zba_VBsUK_3JjIbJ06xwCgivwK3bVW0pRhc28oORJuEQ21QzZbaznCNM8LA&amp;X-OWA-CANARY=J8_MpcJLsE2YKf-kiPm7dCBWHtbf49gY8pKK-mqHsSS7mDwEziJ3ZCtbVFqM95f5fe39ZX_kW-E.&amp;owa=outlook.office.com&amp;scriptVer=20210301002.04&amp;animation=true" border="0" id="_x0000_i1025" crossorigin="use-credentials" style="max-width: 100%; height: auto;">
</span>
<span lang="EN-US" style="font-size:1.0pt; display:none">
</span>
</p>
<p class="MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span lang="EN-US" style="font-size:1.0pt; display:none">
<br id="yw-redacted-redacted--tod">
</span>
<span lang="EN-US">&nbsp;</span>
</p>

vs healthy:

<p class="MsoNormal" style="margin: 0in; font-size: 10pt; font-family: Verdana, sans-serif; color: rgb(255, 255, 255) !important; line-height: 0%;" data-ogsc="black"><span style="font-size:1.0pt; display:none">
<img data-imagetype="External" src="https://t.yesware.com/t/r/redacted/spacer.gif" id="_xredacted_iredacted">
</span>
<span style="font-size:1.0pt; display:none"></span>
</p>
<p class="MsoNormal" style="margin: 0in; font-size: 10pt; font-family: Verdana, sans-serif; color: rgb(255, 255, 255) !important;" data-ogsc="black"><span style="font-size:1.0pt; display:none">
<br id="yw-redacted-redacted--redacted">
</span>
</p>

This is interesting huh, it replaces the source with an attachment 🤔

wsoccorsi-yw commented 3 years ago

It might be helpful to note, https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_other-mso_o365b/inline-images-not-showing-up-in-office-365-outlook/b54ea10e-8cf4-4396-9836-0b4a1c24ff7b. The thread goes into a private chat but maybe something useful in that discussion.

Edit: I've pulled on the notion of turning off images and inline images but can't repro this. I figure you might ask to play with those settings

exextoc commented 3 years ago

Just to clarify you did this in Outlook Win32 Desktop (NO OWA involved at all).

1) Inserted the HTML in Mail 2) Sent it with delay send in Outlook 3) Pulled the HTML of the item.

Is there a chance we could see the HTML between steps 1 and steps 2? (or did you do that an that is the "healthy" HTML you sent?

The replaced image link looks suspicious.

https://attachments.office.net/owa/redacted_user_name%40flexera.com/service.svc/s/GetAttachmentThumbnail?

This looks like a URL that OWA uses to display an image when viewing in OWA (which is why I'm asking if OWA was involved in your repro at all)

I realize this is close to the url you sent before, but this shouldn't have happened if only Desktop Outlook was involved.

Is there a chance the User may have a COM add-in that is working to do this?

exextoc commented 3 years ago

I realize I may have glossed over a point: How are you getting the HTML from the messages when I say "Pulled the HTML of the item" Are you using OWA? or Using Desktop Outlook Visual Basic or Our Office.JS APIs via Desktop Outlook?

wsoccorsi-yw commented 3 years ago

Sure so I can help clarify a few points.

  1. The user set up a delay on Outlook Desktop
  2. In order to use AoS I had to have them "click send" to insert the HTML
  3. This email is then sent to the outbox
  4. I "move" the item to drafts
  5. I then go to OWA to inspect element and copy the HTML which is listed here

I've done this on my machine (the healthy HTML) and the users machine.

They do not have COM.

I'm assuming you want me to get even closer, and in order to do that I will have to write a special feature which will allow me to check OWA drafts directly after insertion (as of right now these API's can only work on send). What I mean is I will have to use prependAsync with allowEvent set equal to false and repro with a user.

I do also question the attachments link, its interesting that the users email gets inserted into the path.

exextoc commented 3 years ago

Okay, sorry. Accessing HTML on OWA is what's causing confusion here. Rendering mails in OWA translates Attachments Images, into those weird links, which is why we were getting confused as to how Outlook Desktop was somehow inserting OWA code.

The HTML we need, needs to come from the email itself, not after it has been rendered. The easiest way to do this is to use our JS api. Office.context.mailbox.body.getAsync() OR simply use the VBE Editor Macro in Outlook, to dump out the HTML body.

File Options -> Customize Ribbon -> Add the Developer Tab to the Ribbon:

image

On any POPPED Out Email you can do the following. (Must be popped out. the command for a reading pane mail is different)

1) Developer Tab -> Visual Basic 2) Bring up the Immediate Window (Ctrl-G) 3) Type type the follwing command "?ActiveInspector.CurrentItem.HTMLBody" image 4) This will dump out the HTML Content of the mail.

If you have permission issues, you may need to adjust trust center settings under: File->Options->Trust Center-> Macro Settings.

What we should do now: 1) Create New Mail. Use Prepend Async / body.setAsync() to Insert Text (prepend is closer to what appendOnSend actually does) 2) Capture HTML 3) Send the Mail (delayed) 4) Capture the HTML from the Outbox 5) Actually Send 6) Capture the HTML from the Sent Items 7) Capture the HTML from the receiver's inbox in Outlook Desktop.

This eliminates OWA from the equation, which should clear up those weird links we were seeing.

I'm trying to figure out where the text is being transformed. My suspicion is that it is either done client side during the Send Process, and is a feature that we don't know about (thought I have followed up with the owning teams, and nobody knows of a feature that would do this). Or it is being done on the server somewhere.

wsoccorsi-yw commented 3 years ago

Thanks for the in depth way to do this, going to have to find time on the clock with a user to perform these operations. Will write back here soon with the info!

wsoccorsi-yw commented 3 years ago

Hello! Following up, we are still trying to get a user to hop on a call with us and reproduce this issue to grab this info. As of right now I've found another example of this, where the user has the src tag changed but its not pointing to image001.png. I thought it might be interesting and give you another thread to pull on:

<p class=3D"MsoNormal" style=3D"line-height:0%">
<span style=3D"font-size:1.0pt;display:none"><img id=3D"m_redacted=41_xredacted_iredacted"src=3D"cid:1784588d1f24cff311"></span><span style=3D"font-s=ize:1.0pt;display:none">
<u></u><u></u>
</span>
</p>
<p class=3D"MsoNormal">
<span style=3D"font-size:1.0pt;display:none"><br id=
=3D"m_redactedyw-redacted-redacted=redacted--tod">

Edit: It turns out this user is on Mac OWA which is even stranger so I believe this points more and more to the function/API

exextoc commented 3 years ago

@wsoccorsi-yw Can you help with following questions on OWA issue :

  1. The above html from OWA is it from sent items of sender or inbox of recipient?
  2. Is the sender able to see the inline image in sent items in OWA?
  3. Is it happening on different browsers for same user or any specific browser?
  4. Can you share the snapshot of html similar to what is requested on Windows?
ghost commented 3 years ago

This issue has been automatically marked as stale because it is marked as needing author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. Thank you for your interest in Office Add-ins!

ghost commented 3 years ago

This issue has been closed due to inactivity. Please comment if you still need assistance and we'll re-open the issue.

wsoccorsi-yw commented 2 years ago

Hi @exextoc, I'm back with more information! Sorry for the long hiatus this was hard information to gather.

Taking a step back from this thread, you requested OWA information. However I was unable to get information from a user experiencing this on OWA but have all the information from Outlook Desktop for Windows.

With this information I can answer most of the questions you listed above for Desktop, however using prependAsync has a different bug which I will go into detail below. Some things to note are, everything is happening "onSend" and probably not associated with your team however, I would be happy if you could pass this information along.

  1. Create New Mail. Use Prepend Async / body.setAsync() to Insert Text (prepend is closer to what appendOnSend actually does) ✅

  2. Capture HTML I insert the following HTML:

    <p class="MsoNormal" style="line-height:0%">
    <span style="font-size:1.0pt;display:none"><img id="m_1985690788244807349_x0000_i1025"' src="https://ci6.googleusercontent.com/proxy/fake/spacer.gif" class="CToWUd">
    </span>
    </p>

    Right after the call finishes I go ahead and check the DOM and I see everything is in order 😄 , this makes it in full.

  3. Send the Mail (delayed) Missed this step please let me know if you need this information, I can circle back

  4. Capture the HTML from the Outbox Missed this step please let me know if you need this information, I can circle back

  5. Actually Send ✅

  6. Capture the HTML from the Sent Items Missed this step please let me know if you need this information, I can circle back

  7. Capture the HTML from the receiver's inbox in Outlook Desktop. Well this is the strange part, this is completely gone, I see <p class="MsoNormal"></p> prepended but all my content is gone. I have some inkling that on send there is some security feature that is stripping out "tracking pixels" as if I send an image with a different src tag it comes through.

More information: We can repro the src stripping issue with appendOnSendAsync every-time with "New Outlook" for Mac, it might be we can find some answers there, as I am sure your team can repro that at least. Just try inserting that HTML above. This could be related to your team however, as this only happens on append on send.

exextoc commented 2 years ago

So I'm doing something like this (using your HTML) on Win32 Desktop Outlook:

var prependtext = "<p class=\"MsoNormal\" style=\"line-height:0%\"><span style=\"font-size:1.0pt;display:none\"><img id=\"m_1985690788244807349_x0000_i1025\"' src=\"https://ci6.googleusercontent.com/proxy/fake/spacer.gif\" class=\"CToWUd\"></span></p>";

Office.context.mailbox.item.body.prependAsync
(
    prependtext,
    {
        "coercionType" : "html"
    },
    function (asyncResult)
    {
        // showMessage(JSON.stringify(asyncResult));
    }
);

And I'm seeing the HTML in both Sent Items AND the Received Mail.

I wonder if there is something else missing in the repro. Does it differ depending on WHAT email you send it to?

wsoccorsi-yw commented 2 years ago

Sorry it has been awhile, but for background I can't reproduce this either. This only happens for certain users on Desktop/OWA but using appendOnSendAsync with that html on "New Outlook" for Mac you will be able to repro, as I can everytime.

exextoc commented 2 years ago

@wsoccorsi-yw Thanks for reporting this issue regarding appendOnSendAsync. We have been able to reproduce it on Mac Outlook on New UI. It has been put on our backlog. We unfortunately have no timelines to share at this point.

wsoccorsi-yw commented 2 years ago

@exextoc Awesome! Thanks so much for working with me here, please keep in mind this bug can happen on other platforms just consistently on Mac "New Outlook"

meghan-mcqueeney commented 2 years ago

Hi there. I'm a co-worker of @wsoccorsi-yw and noticing this issue with another customer. I am attaching some screenshots showing this user's setup if it might be helpful: image (4) image (5) image (6) image (7)

exextoc commented 2 years ago

I unfortunately don't think this is actionable without a specific repro that is showing the issue (see previous responses). i.e. ideally there would be a scriptlab gist that could be shared and reproduce the issue. (or at least do so consistently on a specific machine) to help us identify what may be causing the issue.