Custom stylesheet not working after 3.0 update

[lfk-cbrain]

When I am trying to link a custom stylesheet, in the path "asciidoc.preview.style": "C:/Projects/DocWork/antora.css",

I get the error Could not load 'asciidoc.styles': C:/Projects/DocWork/antora.css

I have checked in the network view in developer tools, and see the following:

It get a 404 error, and a wrong path. Can be tested by inputting file:///c%3A/Projects/DocWork/solution-dev-en-GB/C%3A/Projects/DocWork/antora.css and I get ERR_FILE_NOT_FOUND from Chrome.

If a try to make the path relative ../antora.css, I get the correct path in the GET request, but now a 401 error.

This can be tested by inputting file:///C%3A/Projects/DocWork/antora.css and I can successfully see the file. But it seems VSCode cannot access it (the unauthorized status code). I have tried to run VSCode in administrator mode. The workspace is trusted.

I have tried changing it to C:\\Projects\\DocWork\\antora.css, but it does not work either.

If I rollback to a version prior to 3.0 everything works fine. Currently on 2.9.8 and it works.

System information:
Version: 1.79.1 (system setup)
Commit: 4cb974a7aed77a74c7813bdccd99ee0d04901215
Date: 2023-06-12T16:14:05.102Z
Electron: 22.5.7
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Windows_NT x64 10.0.19045
Extension version: 3.1

[ggrossetie]

For portability, VS code is using URI and the stylesheet is now loaded from your workspace. So you will need to use a workspace relative path to your stylesheet.

[ggrossetie]

I'm not sure why we get a 401 when the folder is trusted. It seems like a limitation/bug of VS code.
In my opinion, if /path/to/trusted is trusted in your workspace the following URI should work:

https://file+.vscode-resource.vscode-cdn.net/path/to/trusted/style.css

Maybe you should open an issue upstream (or look for an existing issue)? https://github.com/microsoft/vscode

[ggrossetie]

Upstream issue: microsoft/vscode#187697

[lfk-cbrain]

Thanks for the quick reply! Let's hope vscode will fix it.

But how come it works (link to my stylesheet outside my workspace folder) when I rollback your extension?

[ggrossetie]

But how come it works (link to my stylesheet outside my workspace folder) when I rollback your extension?

We were loading the stylesheet using Node fs API (basically bypassing VS code security model). Now we are using the fs module provided by VS code which is compatible/supported on https://github.dev

[Bteubl]

Hello,
I am having the same issue where a custom stylesheet that I've been using for 3 years has stopped working after the latest automatic update in VSC. Do you know if this issue will be fixed in the next update?

[ggrossetie]

You can still use your custom stylesheet if you move it into your workspace. If you want to use a stylesheet from a trusted directory then it's an upstream issue and I don't know if Microsoft will fix it in the new release. See the link to the upstream issue in my previous comment.

[Bteubl]

Thanks for the information. This is the error that I'm seeing when I load the preview. I believe that my stylesheet has always been in my workspace directory. I tried moving it to a different location by copying and pasting it, do I need to remove it from the location it's referencing altogether?

[ggrossetie]

It does not help to hide the path to your stylesheet. Let's say that your workspace is /path/to/workspace and your stylesheet is in /path/to/workspace/css/vscode-asciidoc-preview.css then the setting asciidoc.styles should be css/vscode-asciidoc-preview.css.

[brkerez]

Hello,
just fyi - I have vscode workspace security completely disabled, I can't specify trusted folders, and vscode does not load the CSS either. I wonder if solving upstream microsoft/vscode#187697 could fix it

However, I can solve that by copy/hyperlink my stylesheet to every workspace and potentially creating a workspace scoped settings.json to specify the path to css. One can even argue that having everything inside the workspace is the proper way, I find it a little annoying, but a simple script will solve that.

But. I very often edit small adoc documents without a workspace, so that means for those files, I have to say bye-bye to proper preview completely, I don't see any workaround for that.

[ggrossetie]

But. I very often edit small adoc documents without a workspace, so that means for those files, I have to say bye-bye to proper preview completely, I don't see any workaround for that.

Are you saying that it does not even work when the stylesheet is in the same directory as the AsciiDoc document (opened without a workspace)?

As mentioned in the upstream issue, it's possible to add a list of accessible directories on the WebView. So it might be possible to improve the situation.

The one thing I want to avoid is relying on Node's built-in fs module (for portability and security reasons).

[ggrossetie]

We might be able to workaround this issue by (resolving if necessary) and adding the directory that contains the stylesheet as localResourceRoots in the WebView: https://code.visualstudio.com/api/extension-guides/webview

[brkerez]

But. I very often edit small adoc documents without a workspace, so that means for those files, I have to say bye-bye to proper preview completely, I don't see any workaround for that.

Are you saying that it does not even work when the stylesheet is in the same directory as the AsciiDoc document (opened without a workspace)?

I'm sorry for the slight delay :)

I'll try to clarify. The small adoc files all share my common custom css style. So when I have many small adoc files scattered across multiple directories, I want to avoid copying that CSS file into every one of them. Because then, when that CSS changes, I would have to update all the files everywhere. I maybe could use fs links but that creates problems with git on windows not to mention that I simply don't want to place the css into every dir. So I keep one central CSS file in one location in my git repo with scripts that that the adoc and the mentioned css and produce the final HTML.

So before, I was able to set the css location in vscode preferences and would see the proper preview for all of our asciidoc files.

[ggrossetie]

@brkerez @Bteubl @lfk-cbrain I just released version 3.1.10, could you please give it a try?
Also, I've discovered that you can use stylesheets from GitHub using jsdelivr. For instance:

https://cdn.jsdelivr.net/gh/darshandsoni/asciidoctor-skins@gh-pages/css/adoc-foundation-potion.css

[lfk-cbrain]

It's still not working correctly. Also in my company we're not using GitHub, so I don't think that jsdelivr will work for us. But it seems smart! :)

3.1.10 (style sheet not loaded correctly):

2.9.8 (how its meant to look like):

[SjoerdV]

I have a situation where the 'workspace' setting for 'asciidoc.preview.style' is overridden by a nested 'folder' .vscode/settings.json.
In this case it seems the overridden css (with ../../) is being loaded properly, but the error 'Could not load...' in the UI still occurs.

I also seem to have lost the white background in the preview, is that a setting somewhere? dark/light mode specific for the preview perhaps?

Would be nice if some stability is achieved at some point in time. Constantly debugging ones 'Notes Apparatus' is pretty counter productive...

[ggrossetie]

@SjoerdV could you please open a new issue with a reproduction case?

This is an upstream issue and the only known workaround is to by-pass VS code security model which is less than ideal.
I would recommend avoiding relative paths and load the stylesheet either from https:// or from the workspace. Using symbolic links might help.

[SjoerdV]

@ggrossetie I'm a little lost. The github option (your https example) is a no go for me as the files are not on github (and I will not go and add duplicate files anywhere in the cloud), so that leaves symbolic links.

I did an ln -s to the css file, that created a link right next to the settings.json file.
Than I tried referencing this file using

• only the file name -> did not work
• the relative path seen from the workspace -> did not work
• full path -> did load the css, but the error 'Could not load...' still showed (mentioning the full path I configured, while it is actually rendering correctly...) I must say that I already had this situation without the symbolic links, so there is no gain.

So while editing a file this error would continue to pop-up, as you can imagine not a great experience.

For the non-white background I finally just added, problem solved:

body {
  background: white;
}

[ggrossetie]

@lfk-cbrain @SjoerdV you might be experiencing another issue here. Could you please provide a minimal reproduction case? With the latest version I was able to load a stylesheet from outside a workspace.

[ggrossetie]

The remaining issue is described here: #848