Windows: doesn't render files in WSL$
thoni56 opened this issue ยท 7 comments
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
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... ๐
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.
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.
- Open
cmd.exe
as administrator (right-click, "Run as administrator") - Create a symlink
mklink /D docs \\wsl$\Ubuntu-20.04\home\ggrossetie\docs
- Open the symlink in your browser (file path should be:
file:///C:/.../docs
)
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!
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)
You should probably mention that this issue happens in a WebExtension with "Access to local files" enabled.