Error loading JavaScript in SAFE app

I’m debugging an error when loading JavaScript linked to by index.html.

Uncaught SyntaxError: Unexpected token <

./safe files put ~/tmp/hellosafe/dist/ --recursive
FilesContainer created at: “safe://hnyynyz31hqc4os8oq59b1r4rmckamdf19idhgowcafz3cbe9xz1qzxk4abnc”

  • /Users/latch/tmp/hellosafe/dist/artifacts/bundle.js safe://hbkygyd531gfh7hf69cxi63x93m6ui6eecspwaromkf8e4rmek3pu5ity9
  • /Users/latch/tmp/hellosafe/dist/artifacts/hellosafe.wasm safe://hbyyyyd51s4ssgq8pgdtdhn8tyjfzwa7fofqf11p6358zht6amjgz8cf3i
  • /Users/latch/tmp/hellosafe/dist/index.html safe://hbhybyd6shxcy83toh8mnqg963n8mxn78acx1zss1etut66crqbzwry8jj

./safe cat for the three resources outputs the expected content.

./safe cat for the FilesContainer outputs:
Files of FilesContainer (version 0) at “safe://hnyynyz31hqc4os8oq59b1r4rmckamdf19idhgowcafz3cbe9xz1qzxk4abnc”:
| Name | Size | Created | Modified | Link |
| /artifacts/bundle.js | 44942 | 2020-01-22T06:33:28Z | 2020-01-22T06:33:28Z | safe://hbkygyd531gfh7hf69cxi63x93m6ui6eecspwaromkf8e4rmek3pu5ity9 |
| /artifacts/hellosafe.wasm | 880246 | 2020-01-22T06:33:28Z | 2020-01-22T06:33:28Z | safe://hbyyyyd51s4ssgq8pgdtdhn8tyjfzwa7fofqf11p6358zht6amjgz8cf3i |
| /index.html | 187 | 2020-01-22T06:33:28Z | 2020-01-22T06:33:28Z | safe://hbhybyd6shxcy83toh8mnqg963n8mxn78acx1zss1etut66crqbzwry8jj |

index.html contains:

<!doctype html>
<html lang="en">
    <meta charset="utf-8" />
    <title>Hello SAFE</title>
    <script src="/artifacts/bundle.js" defer></script>

Using the SAFE Browser dev tools, (Sources) the /artifacts/bundle.js file is shown as having the same contents as index.html and reporting the error on the <!doctype html> line. However, ./safe cat retrieval of the bundle.js file using its xor-url outputs JavaScript as expected.

@anon78698497 how are you accessing index.html in the browser? Directly at its xorurl? Or at an NRS url? Or at the filecontainer?


safe://hbhybyd6shxcy83toh8mnqg963n8mxn78acx1zss1etut66crqbzwry8jj. Pardon me, I should have included that fact.

Perhaps you need to load the site on the browser using the FilesContainer xorurl instead: safe://hnyynyz31hqc4os8oq59b1r4rmckamdf19idhgowcafz3cbe9xz1qzxk4abnc ?

1 Like


I did try that however I can’t speak to the results other than it causing this crash.

I thought that crash is only when opening the dev console? aren’t you able to load the site correctly?

As a tip, if you upload your files/website onto the shared vault it’s easier to troubleshoot as we can fetch the exact same files and using the xorurls you share, just mentioning if you find that convenient for reporting issues in the future.

1 Like


Yes true, that is when opening the dev console. index.html does load, from looking at the title on the tab, however I can’t verify the loading state of the JS/WASM resources without the dev console.

Thanks for the shared vault offer.

1 Like


Having figured out a workaround to this bug I can finally confirm that that is the solution.

When loading the XOR-URL of index.html in SAFE Browser, the contents of the JS file are reported to be the same as index.html, generating the syntax error.

When loading the XOR-URL of the FilesContainer containing index.html, the contents of the JS file are as expected.

I would consider the file handling when directly visiting index.html to be a bug in SAFE Browser. I briefly searched the repo’s issues and did not find it reported. Please tell me if I missed it.

Moreover, FWIW having read the entire SAFE CLI user guide I believe additional documentation would be helpful. A table describing the default handling of the various container types by official SAFE programs would be helpful.

For example, the behavior of SAFE Browser to automatically retrieve index.html of a FilesContainer.
The documentation contains:

e.g. the SAFE Browser would be automatically fetching the index.html file from it and rendering the website to the user.

While the behavior is intuitive and reasonable it should be directly and explicitly documented. If it is documented elsewhere, perhaps in a more general SAFE architectural document, that should be linked to.

Yes, i suspected that was the issue, and I don’t think that is bug, when you are fetching the index.html using its location the browser or any client app you use for that doesn’t have any clue that file is linked/contained from another content like a FilesContainer (in fact it could be linked/contained from more than one FilesContainer), the index.html xorurl is a direct link to the content of the file but nothing else, not even its name or other metadata, so there is no folder hierarchy that could be found/realised from that xorurl by any app or the network.
On the other hand retrieving the index.html through a path from a FilesContainer, the client knows there is a hierarchy/structure and where the file fits into it, so it can resolve a relative or absolute path link found in the content of it. I’m not sure if it’s clear enough, please just ask if not, I’ll try again.

About documenting this behavior, i think it shouldn’t go into a CLI doc but perhaps the browser doc, so I’m with you we are probably missing a place where to start documenting this type of things. However, this in the future won’t be even defined by the browser or app you are fetching the content with, as the default entry to a site shall/will be defined in the RDF content itself, so what we have now is a temporary thing until we have RDF, at that point a browser app will have to look at what it’s defined there as the default entry page, which was defined by the app which wrote the content, which in turn may have been chosen by the user.



I believe I comprehend your point that by accessing the index.html file directly, there is insufficient context to know from where to resolve the linked JS file. IIUC, I would argue that if a linked file cannot be resolved, it should be handled differently. For example, under Network in dev tools the status code for the JS file is 200. That gives a false impression that the file location was resolved and its contents loaded.

Wouldn’t handling it as a 404 be more intuitive and correct?


I would think so yes, it should be closest to whatever happens on any other browser for links not found, let’s wait fro @joshuef comments/knowledge about the situation in the browser for this scenario, as he for sure knows how unresolved links are handled by it.

1 Like

Yeh, this is a bug. It’s returning the same file as attempting to resolve it at the xorurl, but we only find that same file. So it’s currently returning it, whereas we should probably 404. This is a bug in our resolution logic. Can you file an issue for the same please @anon78698497 :bowing_man:

As for documentation, yup, we should have some. It’s not been a priority as things browser/API side are still far from complete.

If you fancy taking a crack at documenting things in browser-land, PRs are super welcome!

We do have this document though it’s largely reflective of the old APIs. I’ll dive in now to remove what’s irrelevant, but if you wanted to note your findings on web development, that’d be the best place for it :+1:

Edit: Quickly updated the docs to remove old refs in the current pending pr:, in this commit.



I won’t have a quarantined box suitable for using Big Tech services for several months unfortunately.

I will be when the above issue is addressed.

@anon78698497 can you republish your site after the testnet wipe please :bowing_man:

also, what OS are you on?

1 Like


I’ve only published it to the local vault. Would you like for me to publish it to the shared vault?

macOS 10.14.5.

1 Like

Yes please :+1:

1 Like


I’ll do so when SAFE Browser is updated for SAFE CLI 0.7.2.

You can reproduce it with this safe://hbhybydrr6htazoz7e7iho6nn9rooshfbiayo6bsm6xzjnksoktf1h6qii


FYI @anon78698497 should work against the CLI.

It doesn’t have any fixes for anything else in there yet though (and also is alpha, so may not be super stable).

1 Like

@bochaco looks like this isn’t a purely browser based issue,

safe cat safe://hbhybydrr6htazoz7e7iho6nn9rooshfbiayo6bsm6xzjnksoktf1h6qii/artifacts/bundle.js returns the same.

(will make an issue for this in safe-api). We should be 404ing since there can be nothing relative on the ID.