Do not use Blob/FileReader modules in UWP

[Julio César Rocha (JunielKatarn)]

Description

Do not add BlobModule nor FileReaderModule to the default CxxModule list when running a UWP MSRN instance.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Why

Undefined object sharing behavior in UWP (as opposed to Desktop) will cause a malfunction of HTTP/fetch workflows due to a misconfigured Blob module.

Resolves #10036

What

• Conditionally compile the code that adds BlobModule and FileReaderModule to the default modules' list in the InstanceImpl class.
• Defined Blob.EnableModule runtime option.

Microsoft Reviewers: Open in CodeFlow

[Deleted user (ghost)]

Hello Julio César Rocha (@JunielKatarn)!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 10 hours. No worries though, I will be back when the time is right! 😉

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[Alexander Sklar (asklar)]

Undefined object sharing behavior in UWP (as opposed to Desktop) will cause a malfunction of HTTP/fetch workflows due to a misconfigured Blob module.
Julio César Rocha (@JunielKatarn) could you clarify what about UWP makes this not work / how it's related to the "invalid response" error? Ideally we don't add further behavior forking unless there's a clear platform difference

[Julio César Rocha (JunielKatarn)]

Undefined object sharing behavior in UWP (as opposed to Desktop) will cause a malfunction of HTTP/fetch workflows due to a misconfigured Blob module.
Julio César Rocha (@JunielKatarn) could you clarify what about UWP makes this not work / how it's related to the "invalid response" error? Ideally we don't add further behavior forking unless there's a clear platform difference

Updating the summary.
In short, it's the ad-hoc property bag used for the Desktop DLL which does not get used by MSRN's modules.
While we figure out a common way to initialize such property bag for both variants, the decision is not to fork functionality, but to postpone enabling Blob/FileReader in UWP.
Meaning, UWP's behavior is mean to stay unchanged for now.

[Alexander Sklar (asklar)]

Undefined object sharing behavior in UWP (as opposed to Desktop) will cause a malfunction of HTTP/fetch workflows due to a misconfigured Blob module.
Julio César Rocha (@JunielKatarn)

        Julio Cesar Rocha
        FTE could you clarify what about UWP makes this not work / how it's related to the "invalid response" error? Ideally we don't add further behavior forking unless there's a clear platform difference

Updating the summary. In short, it's the ad-hoc property bag used for the Desktop DLL which does not get used by MSRN's modules. While we figure out a common way to initialize such property bag for both variants, the decision is not to fork functionality, but to postpone enabling Blob/FileReader in UWP. Meaning, UWP's behavior is mean to stay unchanged for now.

We have ReactInstanceSettings.Properties as the mechanism for storing/retrieving arbitrary properties in RNW
a) can Office not use that? (cc Andrew Coates (@acoates-ms) for comment)
b) Is there an issue filed/ETA to undo this workaround and get us at parity?
c) it looks like the breaking change was backported a few releases back, could you please also fix it there

I'm a little concerned that this change went through into public OSS without testing, as any basic [manual] validation with RNTester would have uncovered that this was a breaking change, and then it got backported, breaking OSS customers. I imagine this worked fine for Office Desktop but clearly not for RNW. Could we please slow down in the future and make sure we don't jam things through (esp when a change is backported) without proper validation?

[Julio César Rocha (JunielKatarn)]

Undefined object sharing behavior in UWP (as opposed to Desktop) will cause a malfunction of HTTP/fetch workflows due to a misconfigured Blob module.
Julio César Rocha (@JunielKatarn)

        Julio Cesar Rocha
        FTE could you clarify what about UWP makes this not work / how it's related to the "invalid response" error? Ideally we don't add further behavior forking unless there's a clear platform difference

Updating the summary. In short, it's the ad-hoc property bag used for the Desktop DLL which does not get used by MSRN's modules. While we figure out a common way to initialize such property bag for both variants, the decision is not to fork functionality, but to postpone enabling Blob/FileReader in UWP. Meaning, UWP's behavior is mean to stay unchanged for now.

We have ReactInstanceSettings.Properties as the mechanism for storing/retrieving arbitrary properties in RNW a) can Office not use that? (cc Andrew Coates (@acoates-ms) for comment) b) Is there an issue filed/ETA to undo this workaround and get us at parity? c) it looks like the breaking change was backported a few releases back, could you please also fix it there

I'm a little concerned that this change went through into public OSS without testing, as any basic [manual] validation with RNTester would have uncovered that this was a breaking change, and then it got backported, breaking OSS customers. I imagine this worked fine for Office Desktop but clearly not for RNW. Could we please slow down in the future and make sure we don't jam things through (esp when a change is backported) without proper validation?

a) No. Office uses the Desktop DLL which can't access the whole React Context / ReactInstanceSettings mechanism.
b) No ETA, but it can be done as soon as we resolve the property bag-passing issue.
c) Awaiting for approval of this PR to begin backporting.

[Pablo Barrea (omniboyOK)]

I'm having this same issue after installing 0.70 today.

[Julio César Rocha (JunielKatarn)]

I'm having this same issue after installing 0.70 today.

Can you please elaborate?
After this PR was merged, we managed to enable Blob support.

What error are you getting?
A GitHub issue with specific repro steps would be much appreciated :)

[James Cullis (jbcullis)]

Same issue here - error is "Invalid response for blob"

[Tero Paananen (tero-paananen)]

I have this error now on 0.69.11. Issue did not exist on 0.69.7.