Ok so I have a Blob file that I'm trying to save on local disk (the Blob is created locally from an ArrayBuffer). The problem I'm facing is that Outlook for macOS does not want to open a FileSaverDialog or something similar to let the user save the file.

My code is working perfectly in Outlook for Web (OWA) on all browsers (including Safari) and Outlook for Windows.

const blob = new Blob([body]); //body is an ArrayBuffer created locally
const link = document.createElement('a');
if (link.download !== undefined) {
const url = URL.createObjectURL(blob);
link.setAttribute('href', url);
link.setAttribute('download', fileName);
link.style.visibility = 'hidden';
document.body.appendChild(link);
link.click();
document.body.removeChild(link);
}

PS: I have tried using window.open(blob);, but Outlook for macOS throws an error in that situation: "There is no application set to open URL blob:https://..."

PS 2: I have also tried using Office.context.ui.displayDialogAsync(url, { height: 100, width: 100, requireHTTPS: true });,but still getting the same error.

How am I supposed to prompt a SaveFileDialog for the user ? Thank you in advance

We have been told that support for add-ins in shared mailboxes will be added to Outlook in Q2/Q3 of 2019. Thus, we have started rolling out support for shared mailboxes in our add-in too.

As part of this, we have noticed that the add-in icons are only rendered in the context of a shared mailbox element if the user is in the _old look_ of Web Outlook.

Since more and more people will be using the _new look_ as default, users should be able to invoke the add-ins via the new look too.

Please add support for rendering the add-in icons in the _new look_ of Web Outlook too in the context of shared mailboxes.

To anyone who wants a temporary work around: it is currently possible to open an add-in a shared mailbox context in the _new look_ by opening the add-in a personal mail box context, pinning it, and then navigating to a shared mailbox item.

With the preview release of "the new Outlook" on OWA, Office Add-ins are now buried in the drop down context menu in an email. Additionally, it appears they do not follow the same behavior of Outlook on the desktop, where Office Add-ins will show in the larger ribbon if used more frequently.

According to this article, Office Add-ins can be pinned if they are used frequently:

If you were using add-ins in the classic Outlook on the web experience, they will show up pinned next to mail actions or in the drop-down menu once you open an email in the new experience. You can also install more add-ins from the Office Store—simply open an email, click the drop-down menu, and select Get Add-ins. Once installed, add-ins will show up in the drop-down menu. You can also choose to pin frequently used add-ins.
While I can instruct users to pin this for themselves, it does not appear that Office Add-ins can be pinned by an administrator.

For this feature, it would be great for administrators to be able to customize which add-ins are immediately available to the user by pinning them. Office Add-ins being buried in the menu of OWA is not helpful in this regard.

Currently, the default solution of an Office Addins generates two projects that targets .NET Framework 4.6.x. Microsoft should change it to ASP.NET Core. There is a way to adapt the manifest file as seem in https://stackoverflow.com/questions/53991876/change-target-framework-of-a-office-addins-project-from-net-framework-to-net-c/53993432 , but It would be great if the keyword ~remoteAppUrl could refer to another address.
I see this might be a problem as .NET Core is optional when installing VS and might escalate to a broader discusstion.
Also, as asyncronous JavaScript code freaks out migrating VBA (and even web) developers, shouldn't the default template be already in TypeScript (or at least be in the wizard when creating a new solution) as shown in this link? https://github.com/OfficeDev/Excel-Add-In-TS-Start

Currently, there is an api called 'getTypeAsync' which can get the body type( 'html' or 'text' ). But there is no api to change the body type(for example, the api can be called 'setTypeAsync').

The reason why i need this api is for our customers user exprience. For example, when i use mac outlook client, i can get 'text' type by call 'getTypeAsync'. And i can only set plain text in the body by call 'setAsync'. when i try to set html, it can only return failed. But i think display html will be better for our customers. For example, Our customers can clearly see some hyperlinks, phone numbers, etc. what we want to show them. And can use their mouse to easily access our services without the need to copy plain text hyperlinks or phone numbers.

Actually, i noticed that windows 10 outlook client already implemented. And user can switch menu bar to 'Format Text', and can select paste 'As Html' , 'As plain Text' or 'As Rich Text'. I think maybe, it is only windows outlook client feature without mac.