Recently, a client reached out with a puzzling issue: a Power Platform web resource script that had worked flawlessly for two years had suddenly stopped functioning — and without any visible errors. The functionality in question? Generating and launching a SharePoint sync link that would open in the user’s OneDrive/File Explorer, initiated via Xrm.Navigation.openUrl().

At first glance, the script was behaving as expected. We added console logging throughout and confirmed the following:

• ✅ The script successfully generated the correct SharePoint sync link.
• ✅ The link, when clicked in the dev console, worked perfectly.
• ✅ Manually running Xrm.Navigation.openUrl(link) in the console also worked.

But when the script ran during the app’s normal workflow — nothing happened. No error messages, no caught or uncaught exceptions, just… silence.

After exhaustive testing and debugging, we found the root cause: a recent change in how Chromium (and therefore Chrome and Edge) handles pop-ups.

The Underlying Change

In early April 2025, Chromium (starting with Chrome 120 / Edge 135) began strictly enforcing part of the HTML5 Popup spec. Because of this any call to window.open() (which Xrm.Navigation.openUrl() ultimately uses under the hood) must be synchronous and triggered directly by a user gesture — like a button click or keypress — in the same call stack.

If there’s even a single await or setTimeout separating the user interaction from the window.open() call, the browser now silently blocks the pop-up without showing an error or warning in the console.

This means async queries or even small await delays before Xrm.Navigation.openUrl() is executed can cause the function to fail — silently.

The Fix: Promise Chaining From the User Action

To resolve the issue in this specific instance we had to restructure the code to create a true Promise chain from the user action all the way to the final Xrm.Navigation.openUrl() call. This ensured that while we’re still handling async operations, the openUrl() call is tied directly to the user’s gesture through the Promise chain. No async/await gaps, no background events, just synchronous-enough execution to satisfy Chromium’s new pop-up policy.

Why does this matter?

If you’re building or maintaining Power Platform web resources that run asynchronous logic before opening a new window and rely on Xrm.Navigation.openUrl() or window.open() then you may want to give them a check as they could be failing silently.

Key Takeaways

• Don’t delay Xrm.Navigation.openUrl() beyond the user interaction.
• Avoid async/await between the user gesture and the openUrl() call.
• Use .then() chains directly tied to the event listener when you must perform async logic.
• Test your web resources in recent versions of Chrome or Edge, especially post-April 2025.

Have you run into this issue or something similar in your own Power Platform projects? Let me know in the comments — and feel free to share workarounds that worked for you.