mo.ui.table does not render in HTML export on Windows Chrome/Edge

[akshayka]

Describe the bug

Bug report from a user (cc @VivaldoMendes)

Data frames not rendered in the HTML version. I tested it on two different computers (Windows 10 and Windows 11). The data frames are displayed correctly in Firefox but not in Chrome and Edge. I am using marimo 0.7.11, and Python 3.12.4.

Loading time in Chrome and Edge. The fact that the data frames are not displayed in Chrome and Edge (in the static version) may explain why these browsers take a long time to load the entire HTML file (static notebook with 1257KB): around 10/15 seconds. Possibly, they took the time to try to render the data frames, but eventually, they failed and opened the document with the errors. In Firefox, the file opens immediately, and I have no problem with it.

Environment

0.7.11

Windows

Chrome, Edge

Code to reproduce

No response

[VivaldoMendes]

I have checked this problem in Linux, and it does not exist.

So, it seems that Edge and Chrome's inability to render data frames in the static version is an exclusive problem of Windows.

[nicolassoarespinto]

If anyone has the same problem:

• It seems there is a problem in the virtual file system code. Chrome looks for actual files and those are blocked by CORS policy.
• using "marimo export html ..." instead of the UI works
• This snippet from Claude fixed the problem on my notebooks. ( I used it before finding out that the CLI version works, maybe it helps the developers fix the bug):

<script>
  const originalFetch = window.fetch;
  window.fetch = async function(input, init) {
    const url = input instanceof Request ? input.url : input.toString();

    // Check if this is a virtual file request
    if (url.includes('@file/')) {
      // Extract the file name from the URL
      const fileName = url.split('@file/')[1];
      const fullPath = '/@file/' + fileName;

      // Get the base64 data
      const dataUrl = window.MARIMO_STATIC.files[fullPath];
      if (dataUrl) {
        // Convert data URL to blob
        const response = await fetch(dataUrl);
        const blob = await response.blob();
        return new Response(blob, {
          headers: {
            'Content-Type': 'text/csv'
          }
        });
      }
    }

    return originalFetch(input, init);
  };
</script>

[tmespe]

If anyone has the same problem:

• It seems there is a problem in the virtual file system code. Chrome looks for actual files and those are blocked by CORS policy.
• using "marimo export html ..." instead of the UI works
• This snippet from Claude fixed the problem on my notebooks. ( I used it before finding out that the CLI version works, maybe it helps the developers fix the bug):

<script>
  const originalFetch = window.fetch;
  window.fetch = async function(input, init) {
    const url = input instanceof Request ? input.url : input.toString();

    // Check if this is a virtual file request
    if (url.includes('@file/')) {
      // Extract the file name from the URL
      const fileName = url.split('@file/')[1];
      const fullPath = '/@file/' + fileName;

      // Get the base64 data
      const dataUrl = window.MARIMO_STATIC.files[fullPath];
      if (dataUrl) {
        // Convert data URL to blob
        const response = await fetch(dataUrl);
        const blob = await response.blob();
        return new Response(blob, {
          headers: {
            'Content-Type': 'text/csv'
          }
        });
      }
    }

    return originalFetch(input, init);
  };
</script>

I can confirm that using Marimo export on CLI fixes it on my machine.

[gabrielgrant]

Any update on this? Would fixing this just a matter of including that JS snippet (or similar) in whatever template marimo is using to render the notebook?

CLI export works, but

1. requires running a (potentially-long-running) notebook again
2. #3233

[mscolnick]

@gabrielgrant we already do this: https://github.com/marimo-team/marimo/blob/main/frontend/src/core/static/files.ts#L11-L41

I missed this snippet that fixes it. I think the fix is either the 'Content-Type' or using fetch to deserialize the base64 which the snippet includes but the original code did not.

I've incorporated those here: https://github.com/marimo-team/marimo/pull/3240

[gabrielgrant]

@mscolnick Awesome, thanks for addressing! Would test it out, except... #3235 🙃