Office.context.ui.displayDialogAsync throws 5001 I

I'm creating a new Outlook Mail add-in using the Visual Studio project template, where I get a sample displaying properties of the currently selected email.

I've added a button with a click event handler to open a dialog using this code:

  $('#clickMeButton').click(function () {
      Office.context.ui.displayDialogAsync('https://localhost/OutlookAddinTest/MessageDialog.html', {
          height: 40,
          width: 40,
          requireHTTPS: true
      }, function (result) {
          _dlg = result.value;
          _dlg.addEventHandler(Microsoft.Office.WebExtension.EventType.DialogMessageReceived, dialogMessageReceived);
      });
  });

I'm debugging this using the Outlook web client in Chrome:

I don't know if it's relevant for this error, but I can see the following error after the web site is loaded, before I click the clickMeButton:

osfruntime.js:13 Error while parsing the 'sandbox' attribute: 'ms-allow-popups' is an invalid sandbox flag.OSF.OsfControl._createIframeAndActivateOsfControl @ osfruntime.js:13

Isn't the displayDialogAsync(...) function supposed to be used for Outlook Mail add-ins? It might be an issue because it would load another html page within the context of the main Outlook html page. But it doesn't either work in the Outlook desktop client.

The error

The error osfruntime.js:13 Error while parsing the 'sandbox' attribute: ms-allow-popups

comes from the fact that ms-allow-popups is a vendor prefixed css property.

Indeed, you may be aware that your add-in lives in a sandboxed iframe. To be able to do some things, this sandboxed iframe has some extra permissions. For example, popups are allowed but because MS IE, Google Chrome, Firefox etc. did not agree 100% on the sandbox options they have some 'vendor' specific options and ms-allow-popups is one of them (for MS IE). If you browse the iFrame with the devtools you will find the following options sandbox="allow-scripts allow-forms allow-same-origin ms-allow-popups allow-popups".

To conclude on the error, you may ignore it because it is only raised by Chrome because it does not understand the Microsoft vendor prefix. Your code is not responsible for this.

The authentication problem

Now about the dialogAPI. Unfortunately, the dialogAPI is only available for Microsoft Outlook Desktop 2016 recent builds. (>= 16.0.6741.1000.). Make sure your Outlook Desktop is up-to-date. There is no dialogAPI for the web client (aka OWA). You will not be able to see any dialog on Chrome with OWA.

My solution implemented on Keluro is to use the dialogAPI when it is available with the following sample code (typescript).

    hasDialogApi(): boolean {
        var context: any = Office.context;
        try {
            return context.requirements.isSetSupported('DialogAPI', '1.1');
        } catch (ex) {
            return false;
        }
    }

if the dialogAPI is not available (old Outlook 2016, Outlook web clients) we fall back to an authentication flow based on popups. We use a sign in mechanism based on popups combined with SignalR/WebSockets to implement such a flow. See this post and this one to know more.

Conclusion: Outlook desktop builds with dialogAPI are not very widespread at the time of the writing but we see more and more users with them. dialogAPI is crucial for us add-in developers because, with Outlook Desktop without dialogAPI, most of the time a popup based authentication scheme will not work (popup disabled, web socket forbidden etc.). For now, Outlook Desktop without dialogAPI represent the largest part of people sign-in on Keluro.

Note: for debugging the iFrame in Outlook desktop you may be interested in this.