displayDialogAsync - host page receives error:12006 as soon as popup navigates to subdomain about office-js

[shanshanzheng-dev]

@m-hellesen Could you help take a look this issue? Thanks.

[m-hellesen]

Thanks so much for the detailed information and for giving us a sample add in. Questions for you while I look into it, has this worked for you in the past? Have you taken a look at this portion of the docs about cross domain messaging? https://learn.microsoft.com/en-us/office/dev/add-ins/develop/dialog-api-in-office-add-ins#cross-domain-messaging-to-the-dialog-runtime

[cattermo]

Thanks so much for the detailed information and for giving us a sample add in. Questions for you while I look into it, has this worked for you in the past? Have you taken a look at this portion of the docs about cross domain messaging? https://learn.microsoft.com/en-us/office/dev/add-ins/develop/dialog-api-in-office-add-ins#cross-domain-messaging-to-the-dialog-runtime

Hi!
Thank you for looking into this. I did a small rebuild of our Add-In in December last year, moving from iframe popup to popup window. Then this workflow was working (open popup window with own domain -> redirect to other domain -> redirect back to same domain -> pass message to host page). I had to turn off some security headers to make it work (crossOriginOpenerPolicy and crossOriginResourcePolicy) but then it worked.

I'm not trying to message cross domain, I want to send the message after going back to same the same domain as the host page.

[jim22k]

@cattermo I have run into similar issues with Office Online. After redirecting and coming back to the same origin, it can't communicate with the add-in. I suspect it's due to losing the original window.opener reference -- not sure.

I found a solution which involves never redirecting the dialog window. Instead, you pop open a second window and do the redirect flow there. You communicate with the original dialog window via BroadcastChannel.

https://github.com/jim22k/OfficeOnlineDialog/tree/main

[cattermo]

@cattermo I have run into similar issues with Office Online. After redirecting and coming back to the same origin, it can't communicate with the add-in. I suspect it's due to losing the original window.opener reference -- not sure.

I found a solution which involves never redirecting the dialog window. Instead, you pop open a second window and do the redirect flow there. You communicate with the original dialog window via BroadcastChannel.

https://github.com/jim22k/OfficeOnlineDialog/tree/main

This sounds like a good workaround if the office-js team does not manage to solve the problem. Since it's possible to do this with a new popup window, office-js should be able to do it with its popup window...

@m-hellesen Are you still looking into the issue? Any progress?

[cattermo]

Please? Can someone have a look at this?

[m-hellesen]

Hey, I do have someone looking into this. Did the workaround unblock you for now?

[cattermo]

Hey, I do have someone looking into this. Did the workaround unblock you for now?

Ok, great, thank you 🙇 .
Since it used to work late last year I would rather not build a different solution that then have to be removed when the real one starts working again 😬

[yjz2021]

Hey @cattermo, I have been looking into the issue and it seems that the domain policy needs to be changed. Could you please verify if it works when the Cross-Origin-Opener-Policy header is not set to 'same-origin'. Let me know if this solves the issue. Thanks.

[cattermo]

Hey @cattermo, I have been looking into the issue and it seems that the domain policy needs to be changed. Could you please verify if it works when the Cross-Origin-Opener-Policy header is not set to 'same-origin'. Let me know if this solves the issue. Thanks.

Sorry for late response, was bank holiday in Sweden.
Sadly setting "Cross-Origin-Opener-Policy": "unsafe-none" does not make any difference.

[cattermo]

Any progress on this?

[yjz2021]

Hi @cattermo, apologies for the delay. We've investigated and found that the manifest you provided no longer reproduces the host page receiving error:12006 issue. Could you please confirm if the issue is resolved for you? Thank you.

[cattermo]

Hi @cattermo, apologies for the delay. We've investigated and found that the manifest you provided no longer reproduces the host page receiving error:12006 issue. Could you please confirm if the issue is resolved for you? Thank you.

The debugging code is now back for the manifest provided. The error is still the same.
Feel free to also use the reproduction repository that I have created for you 🙏
https://github.com/cattermo/officejs-reproduce-dialog-problem

[yjz2021]

Hi @cattermo, in your repository's index.js file at line 19, it attempts to redirect to 'https://google.com'. This action also sets the Cross-Origin-Opener-Policy, causing it to fail. When there are multiple redirections, it's essential to remove the Cross-Origin-Opener-Policy header from all responses or set them all to 'unsafe-none'.
Could you please try replacing the URL with 'https://example.com' (which does not have such header), and let me know if it resolves the issue for you? Thanks.

[cattermo]

Hi @cattermo, in your repository's index.js file at line 19, it attempts to redirect to 'https://google.com'. This action also sets the Cross-Origin-Opener-Policy, causing it to fail. When there are multiple redirections, it's essential to remove the Cross-Origin-Opener-Policy header from all responses or set them all to 'unsafe-none'. Could you please try replacing the URL with 'https://example.com' (which does not have such header), and let me know if it resolves the issue for you? Thanks.

Oh, that's the key to it!! The receiving link also needs to have a less strict value for that header. This is what happened in our "real" app as well. One of the disadvantages of using helmetjs as a standard.

Thank you very much for finding it! 🙏