Windows: doesn't render files in WSL$

[thoni56]

On Windows with WSL2, a loaded valid file, does not render if that file is from the "WSL side".

• The file is loaded by the browser, so it is not a problem with file access from WSL.
• The file renders perfectly by the extension when moved to the "windows side"

NOTE: A file path to a WSL2 file is something like file://wsl$/Ubuntu/home/... and the dollar sign is converted to "%24" so the file path in the address field looks like file://wsl%24/Ubuntu/home/... maybe that is a clue.

How to repeat:

• Install WSL2 on Windows 10 ;-)
• in a WSL bash shell navigate to a folder with a valid Asciidoc file
• enter explorer.exe . to open a Windows Explorer window in that directory
• in the Explorer window, click on the address bar and copy the path
• paste the path into a browser address field and add the file name then press enter
• the file is read and displayed
• pressing or activating Asciidoc rendering does nothing

[ggrossetie]

Hey @thoni56, which browser are you using? and are you using the latest version of the extension? version 2.6.1?

I will try to reproduce this issue but it's most likely a browser restriction... 😞

[thoni56]

Thanks for looking into this. I'm using latest version of extension on Chrome and Vivaldi on Windows. Neither can render a file-url that references a file on the WSL-side. (Edge does not render correctly no matter if the file is on Windows or WSL-side.)

Firefox on WSL works fine, of course, as does actually Firefox on Windows (rendering a single AsciiDoc-file on WSL-side correctly).

As a slightly different, but maybe related, note, Firefox on Windows does not render a docbook correctly, it fails with "Unresolved directive" on the include:s. This works with Chrome and Vivaldi on Windows.

The files I'm using can be found here.

[ggrossetie]

I can reproduce this issue, the root cause is:

Not allowed to load local resource: file://wsl$/Ubuntu-20.04/home/ggrossetie/docs/issue-504.adoc

This is a security limitation imposed by the browser.

As a workaround, you can create a symlink.

1. Open cmd.exe as administrator (right-click, "Run as administrator")
2. Create a symlink

   mklink /D docs \\wsl$\Ubuntu-20.04\home\ggrossetie\docs

3. Open the symlink in your browser (file path should be: file:///C:/.../docs)

[thoni56]

I feels strange that that should affect only files in WSL storage... Probably the wsl$ (that's some file mapping driver, I suppose) is not the same as a "file".

But anyway, good to know, and thanks again for looking into it!

[ggrossetie]

I think it's a bug (or at least a limitation) of Chromium. You should open an issue at https://bugs.chromium.org/p/chromium/issues/list with a simple reproduction case.

To reproduce this issue you can try to load a file from JavScript using XMLHttpRequest:

const url = 'file://wsl$/Ubuntu-20.04/home/user/file.txt'
const request = new XMLHttpRequest()
request.open('GET', url, true)
request.send(null)

[ggrossetie]

You should probably mention that this issue happens in a WebExtension with "Access to local files" enabled.

[XavierBoniface]

Created issue https://bugs.chromium.org/p/chromium/issues/detail?id=1301709