displayDialogAsync fails in New Outlook with error 12011

[tomasz-i]

displayDialogAsync fails in New Outlook with error 12011 despite same-domain dialog (regression)

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC desktop
• Host [Excel, Word, PowerPoint, etc.]: Modern Outlook / Webview2
• Office version number: latest
• Operating System: Windows 11
• Browser (if using Office on the web): Edge
• API: Office.context.ui.displayDialogAsync
• Manifest: Outlook Web Add-in XML

Expected behavior

DisplayDialogAsync should open new dialog and allow communication between add-in panel and dialog using Office.context.ui.messageParent

Current behavior

Office.context.ui.displayDialogAsync fails in New Outlook for Windows with error 12011, even though the dialog URL and the add-in host URL are on the same domain.

Error message is displayed: "Browser restrictions prevented us from creating the dialog box. The domain of dialog box and the domain of the add-in host are not in the same security zone."

This scenario previously worked in New Outlook, and continues to work in Classic Outlook, which suggests a regression specific to the New Outlook (WebView2) host.

Steps to reproduce

1. Open New Outlook for Windows
2. Load the Outlook add-in
3. Call Office.context.ui.displayDialogAsync(dialogUrl, options, callback);
4. Observe the callback result

Additional details

• The dialog URL and add-in host URL are on the same domain
• HTTPS is used
• No mixed content (HTTP) is involved
• This behavior appears only in New Outlook

Context

This blocks authentication and user interaction flows that rely on dialogs, making the add-in unusable in New Outlook.

Question for the Team

Is this a known regression or a change in dialog security validation logic in New Outlook (WebView2)?
If security zone checks are still enforced, what is the expected configuration for same-domain dialogs in New Outlook?

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• Error when opening a dialog #1959

---

Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)

Solution 1:

12011 occurs whenever an under-the-hood call of window.open fails. This error is only seen on Office on the web, and it means that the user has some browser or web configuration that blocks window.open. The main situation for which it was created is when the user is using IE or Edge Legacy and the add-in is not in the same security zone as the host. But it can happen in other situations too. For example, if Safari is the browser and it is configured to block popups.

Reference:

• Error when opening a dialog #1959 (comment)

Solution 2:

We ask users to please enable pop-ups in order to use the window dialog (if you get the error) and we ask devs to turn on promptBeforeOpen for the window dialog.

Reference:

• Error when opening a dialog #1959 (comment)

Solution 3:

The dialog is opened by using window.open(url, windowName, options). The browser might force windowName to be undefined if it doesn't detect a manual click in a dialog prior to the one we actually want to open, probably as an anti-phishing measure. This information should be documented, or opening a dialog not from the taskpane using promptBeforeOpen: false should be disabled in Outlook.

Reference:

• Error when opening a dialog #1959 (comment)

Powered by issue-sentinel

[nbaliga18]

Thanks for the detailed repro and for confirming that the dialog URL is same‑domain and HTTPS.

Routing this to the Outlook Web engineering team for investigation.
Assigned to: @owaextensibilityteam
CC: @amiraw @samantharamon