Running Esbonio Preview on Codespaces doesn't work

[dp-sgr]

Expected behavior

The preview of a a rst file should be displayed.

Actual behavior

The Preview is broken.

The files are build and i can see a running process/automatically forwared port for esbonio:

The preview is generated from an iframe and i believe that the problem is, that the url to the html page is statically mapped to localhost:

---

Opening the preview in another tab served from the routed Codespace works as expected.
Its only the build-in preview tab in vscode which doesn't work.

---

I've investigated a little bit.

As far as i can interpret the current esbonio code localhost is hardcoded and there is some additional logic when serving via localhost or not. Therefore this should be the problem.

The VsCode LivePreview plugin uses the method:

asExternalUri

In the env object of vscode (sorry there was no direct hyperlink to the function. Just search for "asExternalUri"):

https://code.visualstudio.com/api/references/vscode-api#env

LivePreview Ref:
https://github.com/microsoft/vscode-livepreview/blob/main/src/connectionInfo/connection.ts#L85

---

Maybe this helps a bit. But ive never wrote a vscode plugin before. I din't find any other issues regarding Codespaces or Dev Containers.

Log output

Logs are ok and the html files are all generated. 
This is only a "routing" issue of the preview url in codespaces.

(Optional) Settings from conf.py

No response

[alcarney]

Thank you for such a detailed issue report!

Can I just check which version of the Esbonio extension you are using?

While I've never tried Codespaces myself, I have been using the pre-release version of the extension (v0.90+) with a Dev Container and the preview seems to work ok there. But then again maybe since the container is still on my machine localhost would work fine... 🤔

Thanks also for finding asExternalUri, that looks like it's going to be useful!

[dp-sgr]

Hi @alcarney thanks for the quick response.

I've used the latest released version of the extension (v0.11.0).

I installed v0.95.1 (pre-release). Now im getting the error/loading page of esbonio:

After enabling debug logging, i can see the following output in my Esbonio log:

[esbonio.PreviewManager] Previewing file: 'file:///workspaces/MyProject/source/index.rst'
[esbonio.SphinxManager] No applicable client for uri: file:///workspaces/MyProject/source/index.rst

Which should be this line here:

esbonio/lib/esbonio/esbonio/server/features/sphinx_manager/manager.py

Line 244 in 1c1e5b1

self.logger.debug("No applicable client for uri: %s", uri)

After reloading the VsCode instance i get this output:

[esbonio.PreviewManager] Previewing file: 'file:///workspaces/MyProject/source/index.rst'
[esbonio.PreviewManager] Preview available at: http://localhost:45525/?ws=37923
[esbonio.PreviewManager] window/showDocument: ShowDocumentResult(success=True)

In both cases the "No Content found" loading/error page of esbonio doesn't change. opening another document just outputs the three lines from above .

When im opening the preview (in this case on the container http://localhost:45525/) from outside (with the codespace url) im getting a semi-corrupt output of the html files. Multiple assets are missing (Images, Styles, and so on...).

I also noticed, that the "build" folder is missing even if defined in config. I even removed the folder (from previous builds). It seams that the rst files are now transpiled on-the-fly? Idk. Running the build manually still works fine.

All-In-All: I don't know where to start to debug further. Console outputs are looking ok for me. Only the Browser debug console outputs the following error:

But this could be an error because something before that call goes wrong.
The error hits every time im opening a new file to preview:

[alcarney]

I also noticed, that the "build" folder is missing even if defined in config

Unfortunately, there are some differences in configuration between the two versions. If you haven't found it already, this page from the docs should tell you what you need to adapt your config to the pre-release version.

When I'm opening the preview (in this case on the container http://localhost:45525/) from outside (with the codespace url) im getting a semi-corrupt output of the html files. Multiple assets are missing (Images, Styles, and so on...).

Looking at the screenshot, my guess is that the server hasn't run a full build yet... have you tried editing a file and saving it?

Only the Browser debug console outputs the following error:

I don't immediately recognise those error messages 🤔... perhaps we can ignore those for now.

[dp-sgr]

Sorry for the delay, didn't had time to try it out again.

My build with the pre-release now works now again (thanks for the new configuration docs page).

The preview doesn't work. Im again at the first error:

Opening the forwarded address manually works as expected and i can browse the full generated html sphinx doc:

Maybe its really only necessary to swap the direct url usage to the output of asExternalUri?

[alcarney]

My build with the pre-release now works now again

I could be wrong, but those screenshots look like they are coming from the stable version? (0.11.0)

Maybe its really only necessary to swap the direct url usage to the output of asExternalUri?

I'm hoping that would be enough to at least get the preview to show up... I'm worried getting the websocket connection the pre-release version uses for synchronised scrolling to also work however might be less straightforward... or maybe not? Can't quite get my head around how things in this case 😅

Anyway, I can add a call to asExternalUri to the http url and see what happens - I assume you can install an extension from a *.vsix file in a Codespace?

[dp-sgr]

Sorry you are right. After to many restarts it may have installed the rtm release again.
I cleaned everything up & installed the pre-release again.

The result is the same but im getting the new fancy "No Content Found" page again:

Opening the url directly works fine & im getting my doc:
(I can also click on the link in the log output and VsCode automatically redirects me to the Codespace url)

In the browser log there is the illegal value for linenumber every time im navigating to a rst file again. Because you mentioned the websocket synchronized scrolling, this maybe is a follow-up problem.

When i open the preview page im now also getting a csp error which could also be the issue:

The vscode extension seems to also work with web sockets and the external uri handling and its only slighty different. Maybe that helps? https://github.com/microsoft/vscode-livepreview/blob/main/src/connectionInfo/connection.ts#L97

To the VSIX part: I did't tried it yet but it seems like there is support for that.

[alcarney]

I've opened #905 which will hopefully fix this however, I'm not able to test it myself. Are you able to download this vsix archive?

It should contain a file esbonio-0.95.3-dev905.vsix that you can use with the Install from VSIX... function in your Codespace. Let me know if it fixes it for you 🤞

[dp-sgr]

Sadly this doesn't work :/

Ive googled a bit and also found this issues (any many references issues to that issue):

microsoft/vscode-livepreview#111

Seems to be a general issue with codespaces (When opening the site for the firs time, there is a custom "loading" screen from github).

But even when i open the url manually and then re-load or close & open the preview again it doesn't work.
Im everytime getting the csp error (as mentioned in my last post):

This error occurs everytime im opening the preview.

The line error message always appears when opening a new rst file (doesn't trigger again when im doing something with the preview). -> This may be also an issue but i think it isn't a problem for the preview which is my main importance.

Idk what part of the preview process triggers the error (I don't know how to debug extensions proberly). But i found this line:

esbonio/code/src/node/preview.ts

Line 204 in 971fb91

content="default-src 'none'; style-src 'nonce-${cssNonce}'; script-src 'nonce-${scriptNonce}'; frame-src http://localhost:*/" />

Which maybe also leads to an error because of:

frame-src http://localhost:*/

Maybe there are multiple references to localhost?

I also forked your demo and add a devcontainer config. There i get the same error:

Feel free to start a devcontainer from my fork. I pinned the version directly to the latest published preview. You can also uninstall the version and install the latest one from you via vsix.
https://github.com/dp-sgr/esbonio-demo

[alcarney]

Feel free to start a devcontainer from my fork.

I tried, but for some reason it seems to crash out halfway through connecting...

Despite what the error message says, I definitely have a working network connection 😅

Which maybe also leads to an error because of:
frame-src http://localhost:*/

Ah, forgot about the CSP 🤦‍♂️, yes that will definitely not help the situation. I've now made it so the CSP is derived from the result of asExternalUri - perhaps that will be enough?

You can find an updated version of the extension here

[dp-sgr]

Ok strange :D Never had this issue before.

The new vsix doesn't change a thing. I looked at the iframe and the new csp value. There is now everything configured proberly (in my opinion)

BUT: The nonce is empty in the style block:

Which should be (in this sample): nonce-RKoID2k8ViO38x9ZkK35ay6s5A0PUMcB

The same issues is on the script block:

So maybe there is something wrong withe the nonce now (or this was even the issue before)?
But idk why

[alcarney]

The new vsix doesn't change a thing

That's frustrating :/

This missing nonce values are definitely a problem, without that script block the preview uri is never given to the iframe... 🤔 Like you I don't really know why the values are not there in the codespace, they seem to work as expected when the extension is run locally

The issue I was having yesterday opening a codespace must be a Firefox issue, tried today with Chromium and it appears to work. I will see if I can figure out what is going on 🤞

[alcarney]

I think I've found the root cause!

The code that pushes the uri to preview into the <iframe> checks to see if the message comes from the webview panel, or the page it is hosting.

      // Control messages coming from the webview hosting this page
      if (event.origin.startsWith("vscode-webview://")) {
          // ...
          viewer.src = message.show
          // ...
        }
      }

      // Control messages coming from the webpage being shown.
      if (event.origin.startsWith("http://localhost:")) {
        if (message.ready) {
          // ...
          vscode.postMessage({ ready: true })
        }
      }

However, when running in Codespaces the webview message origin is something like https://1dd71hqg25q30t1qeadg0bqr2efk63ba2nu4g8hp18t0tbd68pl1.assets.github.dev and the webpage message origin is something like https://shining-rotating-banana-5x4r123fq72744g.github.dev/

So, now it's "just" a case of tracking down all the assumptions broken by Codespaces 😅

[alcarney]

I think I've got it! Do you want to try the latest build and see if it works for you?

Unfortunately, you will have to open the two port-forward links in a new tab and reopen the preview window before it will work though

[dp-sgr]

That looks very good. I can now see the preview in the demo fork & also in my custom repo.
Thank you very much for that 👍

Opening the preview once in a seperate tab is the same workaroud as described here: microsoft/vscode-livepreview#111

Maybe we can use the same (upcoming?) fix from the vscode-livepreview plugin to also get it working with esbonio :D
I subscribed to the issue and will keep an eye on that. I don't think we can fix that here if its an general issue with Codespaces.

---

For now im very happy, because our users can view the preview.

One thing to mention: Even if i open both tabs separetely im getting a endless loading panel here:

This is mabe because of the following error:

Or:

So there is the NaN line issue again. -> That isn't a blocking issue for us but its maybe also only a little problem?
Clicking on other lines in the document is always resulting (understandably) in the same error.

[alcarney]

That looks very good. I can now see the preview in the demo fork & also in my custom repo.

Glad to hear it!

Maybe we can use the same (upcoming?) fix from the vscode-livepreview plugin to also get it working with esbonio

I'll definitely be keeping an eye out 🤞

One thing to mention: Even if i open both tabs separetely im getting a endless loading panel here:
This is mabe because of the following error:

Has the server done a full rebuild of the docs yet? I had to change some of the JS esbonio injects into the build. That error looks like the old code might still be present.

So there is the NaN line issue again. -> That isn't a blocking issue for us but its maybe also only a little problem?
Clicking on other lines in the document is always resulting (understandably) in the same error.

To be honest, I don't think I saw that error when testing it myself... I'm hoping it's just a side effect of the WebSocket connection failing 😅

[dp-sgr]

@alcarney Yea. I dind't remove the build dir. After removing it & reloading the window it works now as expected.

Thank you again very much :)

This helps a lot