Outlook on Mac: messageParent Fails on Some Machines, Potentially Linked to &action=displayDialog vs. _host_Info

[Visualq]

Provide required information needed to triage your issue

In an Outlook add-in on Mac, Office.context.ui.displayDialogAsync sometimes appends &action=displayDialog to the dialog URL instead of the expected &_host_Info=..., which we see on all other platforms. On machines where &action=displayDialog appears, messageParent consistently fails to send messages from the child dialog to the parent task pane. On identical setups where _host_Info is used, messageParent works as expected. One machine consistently uses &action=displayDialog (and fails), while another uses _host_Info (and succeeds), despite matching Outlook versions, builds, add-ins, and URLs. This suggests an environmental factor, but we’re unsure if &action=displayDialog directly causes the messageParent failure or is just a symptom.

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: Mac
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: 16.94.2 Build 25022327 (Latest)
• Operating System: macOS Sequoia 15.3.1 (Latest)
• Browser (if using Office on the web): N/A

Expected behavior

I expect Office.context.ui.displayDialogAsync to consistently append _host_Info (e.g., Outlook$Mac$16.00$nl-TR$telemetry$isDialog$$0) to the dialog URL across all machines, enabling messageParent to reliably communicate from the child dialog to the parent task pane. If &action=displayDialog is intentional, I expect messageParent to still work.

Current behavior

On some machines, &action=displayDialog is appended to the dialog URL instead of _host_Info. On these machines, messageParent never sends messages from the child dialog to the parent task pane—no errors are logged, and the parent callback isn’t triggered. On machines where _host_Info is used, messageParent works correctly. While &action=displayDialog correlates with the failure, we’re not certain it’s the direct cause—it could be a related symptom of an underlying issue.

Steps to reproduce

It's hard to reproduce as it appears to be environment related.

1. Open a dialog to remote page:

const authUrl = '<url to authentication page>';
Office.context.ui.displayDialogAsync(authUrl, {
        height: resolution.y,
        width: resolution.x,
        displayInIframe: false,
        promptBeforeOpen: false,
    }, (result) => {
        if (result.status !== Office.AsyncResultStatus.Succeeded) {
            return;
        }

        let dialog = result.value;
        dialog.addEventHandler(Office.EventType.DialogMessageReceived, async (arg) => {
		console.log('Message received from child', arg);
        });
    });

2. Perform a few internal redirects and call messageParent() from authUrl:

Office.onReady(() => {
    Office.context.ui.messageParent(JSON.stringify({ message: "Hello" }), { targetOrigin: "*" });
})

3. On one Mac, the URL becomes https://?action=displayDialog, and no message is logged in the parent. On another identical setup, it becomes https://?_host_Info=..., and the message is received by the parent.

Link to live example(s)

None.

Provide additional details

• On Mac, messageParent fails when the dialog URL uses &action=displayDialog, but works with _host_Info.
• On a failing machine + account combo, it always fails; on others, it always works.
• Reproduction is rare and hard to debug, pointing to an environmental factor.
• Outlook version/build is identical across machines, suggesting it’s not version-specific.
• displayInIframe: true isn’t viable due to CSP/X-Frame-Options restrictions on the auth URL.

Questions:

1. What triggers &action=displayDialog instead of _host_Info? Is it environmental (e.g., cache, account state), legacy behavior, or configurable?
2. Does &action=displayDialog directly break messageParent, or is it a symptom of a deeper issue?
3. Can we force _host_Info to ensure messageParent works?

Context

Our Outlook add-in provides email encryption, requiring authentication via a remote website (Azure AD). This works across platforms, but on some Macs, messageParent fails, preventing authentication data from reaching the add-in. This blocks affected customers from using the service, and the inconsistency undermines reliability.

• Edit:
  Clarified the reproduction paragraph

[github-actions]

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

• Office.context.ui.messageParent not working on Mac in desktop excel #1843

---

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

I see the problem. On Excel desktop for the mac, you can't send a boolean value in the message. I changed true to "true" for my message and it worked. The docs say you can send either a boolean or a string so you might want to leave this open to fix or change the docs. booleans do work everywhere else.

Reference:

• Office.context.ui.messageParent not working on Mac in desktop excel #1843 (comment)

Powered by issue-sentinel

[kumarshrey-msft]

Hi @Visualq,

Firslty thanks a lot for sharing the details of the issue. We tried reproducing the issue at our end using the code snippet you provided but unfortunately we have been unable to get a repro so far. As you mentioned, it might be an environmental factor causing this, but as we are unable to reproduce the bug, it will be difficult for us to comment at this moment.

In the meantime:

1. Can we collect logs from any of the impacted users following this wiki
2. Is it possible for you to share the sample manifest with @exextoc ?
3. Do we know how frequent this scenario is?

[Visualq]

Hi @kumarshrey-msft ,

Thank you for investigating, I expected it would be a tough one to debug. Regarding your request:

1. I will have to discuss this with the customer. It's good to know that it appears that all the users in that specific organisation/tenant (only the Mac users) suffer from the same problem. Also this does not appear to be a Microsoft account issue as we tried it with our own credentials on the customers machine and encountered the same problem. Will respond to this point regarding the logs tomorrow.

2. Yes, @exextoc manifest.xml in order to observe the dialog being opened. In order to test if messageParent is not working, credentials are required which I can provide privately.

3. Not very often, so far this is the only customer suffering from the problem. We had it happen before much more frequent but that problem was due to an instant redirect (initiated from the backend) to another domain before initializing Office.js. Moving the redirect to client side and after the initialization of Office.js solved that problem for most Mac users. Perhaps this might give you some ideas.

Just a quick question, what makes office.js open a dialog with &action=displayDialog?

[Visualq]

@kumarshrey-msft We are unable to retrieve the diagnostics due to the missing "Collect Diagnostics". Nor do we have a windows machine nearby to 'remote' collect the diagnostics. We'll see what we we can do.

[Visualq]

@exextoc we managed to obtain the incident ID:

These are two failed incident IDs: 9ASHZYQ7 / UMPPV92D

After we made a new profile on the Mac it first didn't work however when we tried again on the new profile it suddenly worked. However switching back to the customers main profile it was still broken. This is the incident ID that did work in the new profile: AMVYNWUS (working)

[kumarshrey-msft]

Hi @Visualq,

Thanks for sharing the incident ID. We are still not able to reproduce this bug at our end. Can you confirm if your add-in is hard-coding the re-direct URLs at any stage? Additionally, are you setting any property like window.name explicitly in your flow? This can be one of the reasons behind this unexpected scenario.

In the meantime, will it be possible for you to share the repro video as well with @exextoc in a private GitHub repo?

[Visualq]

@kumarshrey-msft the base url is always the same, once the url is loaded in the dialog we check if a redirect is needed (to a different domain). If it is we redirect the user to that domain to complete authentication. However even without the domain redirect it doesn't work for that customer.

Window.name is not touched. Keep in mind that it works pretty much everywhere except for that customer's Mac.

Have to get back to it with the videos, we have to ask our customer to make the videe.

[sanchitagarwal-msft]

This issue has been fixed. Can you confirm on your side?

[Visualq]

We can confirm it works now. Thank you for your effort.

Was it something we could have prevented?