asciidoctor/asciidoctor-browser-extension

Windows: doesn't render files in WSL$

thoni56 opened this issue · 7 comments

thoni56 commented

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 commented

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 commented

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 commented

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
  1. Open the symlink in your browser (file path should be: file:///C:/.../docs)
  • 👍1
thoni56 commented

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 commented

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 commented

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