Office.onReady does not resolve when using origin-trial token to turn off third-party matching on WebView2
Closed this issue · 4 comments
Provide required information needed to triage your issue
To prepare for the Chrome 3rd party cookie deprecation, we are setting origin-trial header with a token to turn off third-party cookie matching. When this activated, calls to Office.onReady does not resolve, and no errors are thrown.
This is only observed on WebView2, on the Current Channel classic Outlook for Windows.
This issue was observed earlier on March 20, and resolved itself without any change from us some time later. We observed this issue again on May 22.
Your Environment
- Platform [PC desktop, Mac, iOS, Office on the web]: PC desktop (Classic Outlook for Windows)
- Host [Excel, Word, PowerPoint, etc.]: Outlook
- Office version number: 2404 (Build 17531.20152 Click-to-run)
- Operating System: Windows 11
- Browser (if using Office on the web): WebView2
Expected behavior
Presence of origin-trial tokens to turn off hird-party cookie matching should have no impact on Office.onReady
Current behavior
Presence of origin-trial tokens to turn off hird-party cookie matching prevents Office.onReady from resolving
Steps to reproduce
- The add-in manifest and associated
origin-trialtoken are available in this private repo shared to @exextoc
Provide additional details
This issue was observed earlier on March 20, and resolved itself without any change from us some time later. We observed this issue again on May 22.
Context
- This issue prevents our add-in to initialize due to
Office.onReadynot resolving
Is this working again? There was a temporary issue on May 22nd (PST PM), to May 23rd (Afternoon PST). That caused the March 20th issue to return. It should not repro anymore.
Hi @timwan10, this is working again, but we would like to understand the root cause of why this happened, as well as the specific dependencies involved (Outlook version, Edge runtime version, etc).
@timwan10 Yes, this is working. We are also very interested in knowing where this issue was introduced, which helps us assess impact timelines. Thank you!
I don't really think there's a great answer here. What happened was the fix for issue back in March, was accidentally disabled. It was noticed, and the mistake reverted. The dates of impact were described as above (May 22nd evening - May 23rd afternoon).
it affected Outlook builds 16.0.17425.XXXX Through 16.0.17609.XXXX
(I believe all runtime versions of WebView2)