I’ve been leveraging the Office.js Dialog API recently and found a scenario where I just couldn’t get it to behave properly. At the moment this appears to be either a bug or limitation of the Dialog API. I found that the calling MessageParent() from the dialog fails to trigger the registered callback method in the host add-in when running in IE11 (on both Win 7 and Win 8.1)
Following are the steps to reproduce the issue with the Dialog API under IE11 where the messageParent() method fails to trigger the corresponding event back in the host add-in.
Steps to Reproduce
To reproduce the issue I’ve taken the Dialog API example from dev.office.com and hosted in Azure.
Then I updated the manifest to point to the location where I hosted it, and then tried to use it in the different environments (I made no code changes to the example).
For these repo steps I just opened Word Online in IE11 and side loaded the manifest. The issue also exists using Office Desktop on a machine with IE11 installed (but not Edge) as Office will then be trying to use IE11 and you get a similar issue.
On Windows 10 in Chrome or Edge (works as expected)
On IE11 on WIn 7 & Win 8.1 Fails to Communicate back to Parent Add-in
Now if I use the same manifest and try it from Win 8.1 IE11 the pop up dialog fails to send the message back to the parent add-in when you press a button.
If you close the dialog, the dialog close event method does get triggered back in the parent add-in (this is the same behaviour that we observed when developing our add-in).
I am aware of the documented issue of the Dialog API not working in mixed zones under IE (especially with difference in protected mode between the host page and the add-in/dialog URLs).
In the scenario above the host (Word Online) page is in the Internet Zone with Protected Mode off
And the add-in is also running in the Internet Zone with Protected Mode off
Hey, I just faced same issue while using dialog API for AD authenticating and rejected store submission. Do you find any workaround for this?
LikeLiked by 1 person
While calls to messageParent fail to trigger the event back in the host, closing the Dialog API window will raise an event back in the host app. Maybe you can utilize this in your flow.
@cameron – We use the dialog API to render a login page and because of the above issue IE11 shows a blank page. If the user has not got an opportunity to load his credentials then what do to just raising a close event when we don’t have an input to proceed. Is there a solution to render the page properly? and then messageParent fail i can use what you are suggesting to go fwd.
After a successful login you get control over the redirect URL (this page will get loaded into the Dialog API). This is your page so you should have control over it, while it can’t call messageParent to pass back the auth token it can close itself and the close event of the dialogAPI should fire in the parent window (in my experience). The acess token should now be present in the browser cookie cache and if you detect this scenario you can retry your auth and use the cached cookie. Not elegant but it may work for you. Good luck.