OWA: Some images broken when adding as attachments

[barclayadam]

Your Environment

• Platform: Office on the web
• Host: Outlook
• Operating System: Windows 10
• Browser (if using Office on the web): Chrome v98

Expected behavior

When adding an attachment it is displayed correctly in OWA.

Current behavior

Steps to reproduce

Install our test add-in from https://outlook.sig365-uat.com/playgroundmanifest.xml and create a new email. The add-in is a simple one that uses a base64 encoded image as an inline file attachment and uses a CID reference to that inlined attachment.

For quick reference, the problematic code is:

const brokenImage = 'base64 encoding of image';

function setSignatureWithInlineAttachment() {
    Office.context.mailbox.item.addFileAttachmentFromBase64Async(brokenImage, 'image1.png', { isInline: true }, function () {
        Office.context.mailbox.item.body.setSignatureAsync(
            '<img src="cid:image1.png" />',
            {
                coercionType: 'html',
            },
            function () {
                console.log('Done setting signature');
            });
    });
}

Note that the base64 is the encoding of the image found at https://images.uk.sig365-uat.com/cdn-cgi/image/fit=scale-down,w=620,h=200/yn7pmcvqss3whfiu/img_E3KpV5PvkusklkOw/v1.png

As a counter-example of an image file that works check out https://images.uk.sig365-uat.com/yn7pmcvqss3whfiu/img_E3KpV5PvkusklkOw/v1.png (which I have encoded in the variable workingImage in the source of the add-in.

The handling appears to be broken whether base64 or adding as a URL.

Provide additional details

Although not directly related to the above problem (as these console errors are also output on images that work), Google Chrome prints the below errors, which I would not have expected:

cid:image1.png:1          GET cid:image1.png net::ERR_UNKNOWN_URL_SCHEME

outlook.office.com/:1 Access to image at 'cid:image1.png' from origin 'https://outlook.office.com' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.

Context

This is affecting multiple customers using our live add-in where images that should be added to signatures are simply broken in OWA, but work in other platforms fine (i.e. Outlook for Windows)

[exextoc]

Thanks for reporting this issue . It has been put on our backlog. We unfortunately have no timelines to share at this point

[nkkinariwala]

@exextoc - For now I have assigned this bug to you. You can re-assign to a right person accordingly.

[exextoc]

@nkkinariwala Sure, the bug has been put in our backlog. We will update it once its resolved.

[ShadowAnonymous]

Hello i reproduce this problem have you got a solution ?

[exextoc]

Is this still a repro ? We are not able to repro the issue from our end.

[MrDaleQ]

@exextoc please can this ticket be reopened as this issue is not resolved - the reproduction defined by my teammates is still relevant, and we are still seeing this behaviour for customers.

[akshayta23]

We are able to repro the issue at our end (have identified it as transient) and have logged on on-call bug for the same with internal tracking ID 2639681. The team will get back once we have an update on the fix.

[shighosh-msft]

Thank you for reporting this issue. After further investigation, we have found that the API successfully attaches the image consistently on our end. We have tried to repro with multiple accounts / browser combinations as well.

If you are still experiencing this problem, we recommend trying the latest OWA build to see if the issue has been resolved. If you encounter any further difficulties, please don’t hesitate to reach out, and we’ll be happy to assist.

[MrDaleQ]

Hi @shighosh-msft,

This issue is still being reported as an issue to us by our customers - as far as I understand the OWA build is determined by the ExO version published by MS, and cannot be altered by the client?

If this is possible is there any documentation around updating the OWA build used by the ExO instance, and how can this information be found within OWA itself, as the "About Outlook" option does not exist.

[MrDaleQ]

Hi @shighosh-msft

I am now able to replicate this issue on my personal mail account - if I am able to use to console to get this information for you I'd be happy to supply this.

[MrDaleQ]

@shighosh-msft @exextoc is there any additional information on this issue?

[johnny-outreach]

@shighosh-msft @exextoc @akshayta23 Is there any update on this as we are still seeing the issue in production.

[johnny-outreach]

@shighosh-msft @exextoc @akshayta23 Is there any updated on this, this is affecting a number of customers.

[johnny-outreach]

Hi @shighosh-msft @exextoc @akshayta23 I wanted to follow up here to see if there was any further update or information our team and provide on this?

[johnny-outreach]

@shighosh-msft @exextoc @akshayta23 I wanted to follow up here. We are still seeing the issue with Images appearing correctly within Outlook Web.

This issue appears to happen randomly. I composed 10 emails in OWA and encountered the issue once (select "new email"; the issue may occur or may not, discard the email, and repeat the process).

Happy to complete a remote session if this helps.

Edit

Just tested the same process in New Outlook and the issue is the same. Version of New Outlook:

[MrDaleQ]

@exextoc @akshayta23 @johnny-outreach

Please can this issue be reopened. My colleague has posted replication information above but this issue is still closed.

[mobisw-msft]

Hey folks, unfortunately we are still unable to reproduce this issue- having repeatedly retried across repeated sessions and having tried with both the add-in, as well as the broken image suggested. Repeated retries even on the exact reported build number is not leading to anything.

We are keeping this thread open to discuss any further steps we can take. @MrDaleQ , if you can provide console logs for when this scenario occurs, that would be helpful. Do remember to use "https://outlook.office.com/mail/inbox?enableTracing" so that we can get a full set of logs for the scenario.

[mobisw-msft]

Please do not share HAR files over public posts since they may contain sensitive information. Please add these to a private repository and give access to @exextoc for the same. You may revoke access once your issue is answered.

[MrDaleQ]

Hi @mobisw-msft

Thanks for the reply here - we're going to replicate this and get some logs and put them on our repo for you to access.

[johnny-outreach]

@exextoc as requested I have invited you to a private repo where you should be able to download .har files and screen recordings of the issue.

Do let me know of any issues.

[arpitsangwanmsft]

Hey @johnny-outreach / @MrDaleQ!

We could repro the issue once in 10-15 times as mentioned above, with the sample Add-in (https://outlook.sig365-uat.com/playgroundmanifest.xml) provided, which tries to attach a gif file as attachment. Though, the issue could not be reproduced with the png file mentioned in the "Steps to reproduce" section or with any other png / jpeg files. Thanks for .har files and your inputs. We have re-activated the issue in our backlog (Internal Tracking Id 2639681).