*reactR/R/dependencies.R*: Shinyapps.io deployment fails to load *react-tools.umd.cjs* provided by dependency *reactwidget-2.0.0*

[bryce-carson]

I've opened an issue in a Shiny project I'm leading development in to track an issue I'm having with reactR when the application is deployed to Shinyapps.io. The issue (ashokkrish/episim#148) is only present when running there, and does not occur when running locally.

When running on Shinyapps.io, the following warning is printed in the browser console.

Loading failed for the <script> with source “https://bryce-carson.shinyapps.io/Episim/_w_df7e27de/reactwidget-2.0.0/react-tools.umd.cjs”. Episim:51:53

When running the application locally, the react-based widget the application is using is properly loaded, but the following (different) warning is printed.

The script from “http://127.0.0.1:3171/reactwidget-2.0.0/react-tools.umd.cjs” was loaded even though its MIME type (“application/octet-stream”) is not a valid JavaScript MIME type. 127.0.0.1:3171

Are there are any workarounds I could use while waiting for the version of react-tools that reactR depends on to be bumped to patch the MIME type issue?

[marcoquotech]

having a similar problem, seems to have cropped up since v0.6.0 was released.

Refused to execute script from 'https://[redacted]/app_direct/[redacted]/reactwidget-2.0.0/react-tools.umd.cjs' because its MIME type ('application/octet-stream') is not executable, and strict MIME type checking is enabled.

Uncaught TypeError: Cannot read properties of undefined (reading 'reactShinyInput')

when we rolled back to v0.5.0 the problem went away.

one thing i did notice was the changelog for v0.6.0 mentions a move from webpack to vite, and we are still using webpack. could this be related?

[bryce-carson]

Refused to execute script from 'https://[redacted]/app_direct/[redacted]/reactwidget-2.0.0/react-tools.umd.cjs' because its MIME type ('application/octet-stream') is not executable, and strict MIME type checking is enabled.

Uncaught TypeError: Cannot read properties of undefined (reading 'reactShinyInput')

What software environment is your Shiny application running in? Are you using Shiny Server? I'm just curious about the potential differences in environment because the error message you quoted is different, but concerning the same issue.

when we rolled back to v0.5.0 the problem went away.

Good to know! You only needed to change the reactR package version used, right? Did you need to rebuild your JSX after the rollback too?

one thing i did notice was the changelog for v0.6.0 mentions a move from webpack to vite, and we are still using webpack. could this be related?

Hmm... probably, but whether users of the reactR package are using Webpack or Vite themselves to build their own JSX should matter, right?

[danielloader]

To answer the question, Shinyproxy rather than ShinyServer.

[SverreFL]

I get similar error when using cell argument reactable

library(reactable)

reactable(
  iris[1:5, ],
  defaultColDef = colDef(
    cell = function(value) value
    )
)

does not render (on posit workbench) after upgrading reactR to v0.6.0.

index.html:1 Refused to execute script from '[redacted]/s/b494bf1b518226a356fa7/session/viewhtml7880aa5558cd/lib/reactwidget-2.0.0/react-tools.umd.cjs' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

rolling back to v0.5.0 solved the problem.

[jfunction]

Phew! Took me a while but I figured out why (for the exact same app) my deployment wasn't working but my colleagues was working. Pulling the bundles and diffing the manifest.json files solved it - he's on 0.5.0 and I'm on 0.6.0. Fortunately, the name looks similar to reactable and this issue exists! Thanks for the tip about reverting to 0.5.0 🙏

[bryce-carson]

I'm glad this is getting views! Hopefully we'll have a fix soon.

[glin]

I can confirm this affects reactR 0.6.0 with any widget that uses reactR. I missed this too in #83, but https://github.com/react-R/reactR/blob/master/inst/www/react-tools/react-tools.umd.cjs probably needs to be changed back to having a .js extension instead of .cjs.

.cjs doesn't seem to be a standard MIME type, so these files get reported as binary files by web servers apparently. But it seems like browsers can detect these as text files just fine? These files get loaded just fine for me when I view widgets locally, or even on Netlify: https://v0-4-4-9000-1f6a3b8--reactable-docs.netlify.app/

The difference between Netlify and shinyapps.io is probably the presence of a X-Content-Type-Options: nosniff header, which disable browser side MIME detection.

Firefox shows this errorfor shinyapps.io, which sends a X-Content-Type-Options: nosniff header:

The resource from “https://glin.shinyapps.io/shiny-reactable-test/_w_1bb798f3/reactwidget-2.0.0/react-tools.umd.cjs” was blocked due to MIME type (“application/octet-stream”) mismatch (X-Content-Type-Options: nosniff).

Firefox shows this warning for Netlify, which doesn't have the header:

The script from “https://v0-4-4-9000-1f6a3b8--reactable-docs.netlify.app/articles/examples_files/reactwidget-2.0.0/react-tools.umd.cjs” was loaded even though its MIME type (“application/octet-stream”) is not a valid JavaScript MIME type.

[bryce-carson]

Firefox shows this errorfor shinyapps.io, which sends a X-Content-Type-Options: nosniff header:

The resource from “https://glin.shinyapps.io/shiny-reactable-test/_w_1bb798f3/reactwidget-2.0.0/react-tools.umd.cjs” was blocked due to MIME type (“application/octet-stream”) mismatch (X-Content-Type-Options: nosniff).

Firefox shows this warning for Netlify, which doesn't have the header:

The script from “https://v0-4-4-9000-1f6a3b8--reactable-docs.netlify.app/articles/examples_files/reactwidget-2.0.0/react-tools.umd.cjs” was loaded even though its MIME type (“application/octet-stream”) is not a valid JavaScript MIME type.

Indeed, I saw those two different errors; I hope I mentioned them in the issue report. The extra research you did and report makes sense from the error messages reported; I didn't know why they were different, but MIME types were definitely part of the issue!

Thanks for investigating this.

[mbjohnsonmn]

For what its worth, I submitted a support request to the Posit/shinyapps.io team and received that following, which they suggested I pass on here:

Our opinion is that reactR should change these to .js files. .cjs represents CommonJS, which is only intended to run in non-browser contexts. We'd like to keep the header as it helps prevent injection attacks.

The other way around this would be for the shiny server to return a Content-Type: application/javascript header, but that's probably not likely to change for the reasons stated. If we do see this happening more, we may reconsider.

I did downgrade to 0.5.0 from 0.6.0 which solved the issue of the reactable with nested details not being displayed on the server. So, thanks for documenting that.

[idavydov]

This also seems to affect rendering rmarkdown with interactive gt tables.

Here's a minimal rmarkdown:

```{r}
gt::gt(mtcars) |>
  gt::opt_interactive()
```

The error looks like this:

Could not determine mime type for `<...>/reactR/www/react-tools/react-tools.umd.cjs'
Error: pandoc document conversion failed with error 63
Execution halted

[timelyportfolio]

Thanks @glin for all your help with this. I have reviewed and tested. Will submit 0.6.1 to CRAN today.

[timelyportfolio]

On its way to CRAN. Thanks everyone for the report, the diagnosis, and the solution. Closing now, but please feel free to reopen.