Fetch: decoding of non-ASCII characters issue in JavaScript-only runtime of Outlook

[cut2run]

Provide required information needed to triage your issue

Our implementation of bundled JavaScript file for use with launch events in JavaScript-only runtime of Outlook uses fetch API to retrieve JSON files from the server. This implementation worked well in Outlook desktop on Windows version 2308 (Build 16731.20716 Click-To-Run) Semi-Anual Enterprise channel. After upgrade to the version 2402 (Build 17328.20452 Click-To-Run) the fetch is still working fine for JSON with ASCII characters only, but if JSON includes international, non-ASCII characters the fetch's response object text() method would return improperly decoded string. We have confirmed on our QA environment as well that with Outlook upgrade mentioned above the fetch response object failed to decode properly the UTF8 string. We also have XMLHttpRequest implementation of the same functionality and XMLHttpRequest works properly on both mentioned versions of Outlook. Obviously, something was changed for the fetch implementation of JavaScript-only runtime of Outlook from version to version. We have our workaround and will use XMLHttpRequest, instead of fetch, but this doesn't sound right. In fact, I believe Microsoft's Viva Insights add-on uses fetch object to retrieve JSON with international translations of the resources; they should have the same troubles as we are when a user switch the local.

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC Desktop
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: 2402 (Build 17328.20452 Click-To-Run)
• Operating System: Windows
• Browser (if using Office on the web): no

Expected behavior

The fetch's response object text() must return properly decoded UTF8 string according to specification.

Current behavior

The fetch's response object text() returns garbled text.

Steps to reproduce

1. You would need the addon with support of any launch event
2. In javascript handler of the event do the fetch call to the server for JSON file which includes as one of the values international characters
3. in response of this request check the text() or json() return and you will see the text will be garbled.

Link to live example(s)

1. ---

2. ---

3. ---

Provide additional details

1. ---

2. ---

3. ---

Context

Useful logs

The return from fetch ...

The same return from XMLHttpRequest ...

Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.

[JunielKatarn]

@cut2run Could you please provide a small sample JSON file that would trigger this behavior?

[cut2run]

Of cause, this is an example ...

{
    "IDS_ERR_CHANGES_SAVED": "Изменения сохранены.",
    "IDS_ERR_CHANGES_NOT_SAVED": "Ошибка при сохранении изменений.",
    "IDS_ERR_SOMETHING_WRONG": "Что-то пошло не так :("
}

[JunielKatarn]

We also have XMLHttpRequest implementation of the same functionality and XMLHttpRequest works properly on both mentioned versions of Outlook.

This aligns with the known symptoms of this issue. When Blob capabilities are detected, the fetch API will attempt to use them as the default response payload storage (regardless of the incoming content being plain text). We had a bug where the binary UTF-8 content was not correctly handled.

@cut2run I have tested the exact content against our React Native fetch infrastructure (not directly in Office). The response handled reflected in JavaScript correctly.

While we test the scenario in the specific Outlook version you reported, can you try upgrading Office to a yet more recent version?

[cut2run]

@JunielKatarn Thanks for looking into the reported issue. Unfortunately, I will not be able to upgrade my Office, as it is up to date. In fact, the issue is reported after the recent update. We have semi-annual subscription and the version posted is the latest release for this type of subscription. I understand that you've created the new integration test directly against of React Native (which is surprising you didn't have one, but well often we don't have time; it's good you have it now), but We don't know what build of React Native got into reported version of Outlook. So what is your suggestion? The integration test passes most likely against of the master branch of your repo (my guess), This may mean many things, for example, the bug was there, but it is fixed by now, or the bug is in Outlook itself and appears when the React Native is embedded into Outlook. Should the Office.js guys step up and test my "steps to reproduce" against of released version of Outlook? Please advise. As I mentioned before I have XMLHttpRequest override which works as expected and I can use this workaround. But don't you think it should be at least confirmed for this Outlook release or newer Outlook (from monthly channel)?

[JunielKatarn]

@cut2run Thanks to clarify.

It is correct that the RN code base where we just added the test is way more recent than the version you are using. Adding that test to automation (which we had conducted manually before) is just step 1.

Because you have to your subscription's cadence, I will proceed and test myself directly on Outlook, starting with your exact version and comparing to the most recent releases.

[JunielKatarn]

I was able to reproduce the under a very specific (non-default) context.

The affected Office version you are using used can switch between the old and new React Native HTTP clients (the former one does not support Blobs and can have encoding problems). This switching is controlled via Flight Overrides (see File / Settings / Experiment). For now, I will purposefully omit the details of this override.

I used the following code snippet to test the scenario:

    const uri = 'https://raw.githubusercontent.com/microsoft/react-native-windows/196faceb8fc2a6328b9ba0d7a4efea277d35c422/vnext/TestWebSite/wwwroot/static/utf-8.json';
    fetch(uri)
        .then(res => res.text())
        .then(txt => {
            Office.context.mailbox.item.body.setSignatureAsync(`Success: [${txt}]`, () => event.completed());
        }).error(err => {
            Office.context.mailbox.item.body.setSignatureAsync(`FAAAAIL: [${err}]`, () => event.completed());
        });

Result with the override set to true or missing (default):

Result with override explicitly set to false (enforcing old HTTP client):

Office version info:

Microsoft® Outlook® for Microsoft 365 MSO (Version 2402 Build 16.0.17328.20452) 64-bit

React-Native-Windows 0.72.25.0

@cut2run would you be able to share a screen shot of the Experiment window on the affected machine(s)?

[cut2run]

I am working in the corporate environment with publicly released Office standard installation, so my Outlook options do not have "Experiment" tab ...

[cut2run]

@JunielKatarn something caught my eye. By looking at your screenshots once again, I realize you are using Outlook Desktop on Windows new UI. According to documentation Type of runtimes, New Outlook event-based functions running under browser runtime. This is not what was reported. I specifically indicate the scenario reproducible in JavaScript-only runtime. The only way to run React Native (JavaScript-only runtime in documentation) for released versions of Outlook is to run "standard" Outlook (old UI). Probably you can tweak from "Experiment" tab to run add-on functionality under different runtime while using New Outlook (Once again my speculation). But this is not the case. The case is very simple, to run event-based add-on under JavaScript runtime, which is the standard Outlook. This way add-on will be using React Native and this affects ALL regular installations of the posted version of Outlook release. You might still think this is some kind of issue with our environment, but this is not as we confirmed with QA when upgrading Outlook from the previous version. Also keep in mind this is semi-annual subscription, which means we gonna stick with this issue for half a year, even more, it's not just us, but our customers as well, who use the same Outlook version. I just would like to escalate the importance. Please let me know if any additional help is required from my side.

[JunielKatarn]

The screenshots and behavior do correspond to the "classic" Outlook, and the fetch behavior uses a JavaScript-only runtime.

Probably you can tweak from "Experiment" tab to run add-on functionality under different runtime while using New Outlook

Not quite. This behavior (the bug) was inherent to an older React Native HTTP module, which implies the usage of a JavaScript-only runtime.

my Outlook options do not have "Experiment" tab ...

I see. It is likely those overrides are set up from a centralized management system in your organization's case. In any case, the behavior does correspond to the old HTTP client. Will reach out to coworkers involved in semi-annual deployments for further assistance.

[JunielKatarn]

@exextoc The user is very likely being affected by an incorrect set of Experiment Overrides in his semi-annual subscription. He also does not have visibility of such overrides due to the type of subscription.

Please advise on how to audit/correct the deployment. Feel free to contact me offline.

[Oleg-O]

Slava, we'll huddle internally and get back to you.

[Oleg-O]

We're working to get this resolved. I'll keep this post updated with progress.

[JunielKatarn]

@cut2run I have been informed that the necessary changes have been deployed on our side. Can you please apply any available updates to your Office instance, restart Outlook and try again?

[cut2run]

Hey @JunielKatarn , I thought I made it clear that I am using the released enterprise Outlook with semi-annual subscription. My Outlook is up to date, just checked it. It will be up to date for another half a year, despite some security/hot patches updates might come up. So I don't know what this means for us "necessary changes have been deployed on our side". Is this referring to hot patch? In this case, I probably will be able to see/ try it soon, or the fix was added to the "feature" release, in this case, I will see it in half a year. At least tell me Outlook version (https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date ) which includes the "deployed changes" and if this version is from semi-annual channel, I will be able to try it. Sorry, I am not sure how else can I help.

[JunielKatarn]

I thought I made it clear that I am using the released enterprise Outlook with semi-annual subscription.

And you thought correctly. You also mentioned you ran into the issue in version 17328.20452.

(https://learn.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date )

As the link you posted shows, current exact version for the semi-annual channel is 17328.20550. I am suggesting updating to that minor version which should be available for your current channel. That would also match the environment we used to test the solution and eliminate one variable.

I don't know what this means for us "necessary changes have been deployed on our side"

This only means the server-side feature deployment should now be available in all Semi-Annual channels for the version you are using (this does require an app restart to grab such changes).

Sorry, I am not sure how else can I help.

Just confirming whether the issue is fixed on your end:

... restart Outlook and try again?

[cut2run]

@JunielKatarn I have updated Outlook to the latest 17328.20550 version for our subscription type and confirmed the fetch decoding works as expected. Thanks a lot for the effort to everyone on the thread. You are free to resolve the ticket.

[Oleg-O]

Thanks, Slava, for the confirmation!